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[57] ABSTRACT 

A process for the identification of a claimant by a verifier. 
The process is of the public key type, where the public 
exponent is equal to 3. The claimant draws at random a first 
exponent a, calculates r«g" mod n and transmits R=r^. The 
verifier draws at random a second exponent p, calculates 
t»gP mod n, calculates T«t^ mod n and h=Hi(Z), where 
is a hash function, and calculates Z=R^ mod n. The verifier 
transmits to the claimant the numbers T and h. The claimant 
calculates Y«T" mod n, verifies the result Hi(Y), calculates 
H=H2(Y), where is another hash function, calculates 
z=rS mod n, and transmits z and H. The claimant also has a 
secret number S equal to the modulo n cubic root of a 
number I deduced from its identity so that the number S 
verifies S^'=I mod n. The verifier verifies that H received is 
equal to H2(Z) and that 7? is equal to RI mod n. 

2 Claims, 3 Drawing Sheets 
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PUBLIC KEY IDENTIFICATION PROCESS eth root (or its inverse), calculated by the emission 

USING TWO HASH FUNCTIONS authority with the aid of secret elements held by it, is 

called "accreditation", 

BACKGROUND OF THE INVENTION The accreditations deposited in the identity modules can, 

5 initially, be used for passive identification purposes (i.e., 
requiring no calculation on the part of the party wishing to 

The present invention relates to a cryptographic identifi- p^ve its identity). For the verifier, the protocol is then 

cation process enabling a random support, called an identity reduced to the following operations: 

module (e.g. a smart card, microprocessor, computer, etc.), identity-accreditation pair contained in an 

to prove Its identity to means implementmg an application, jq identitv module- 

or an interlocutor having verification means, using a pro to- , , • . .' r , ... 

col setting into action, without revealing the same, one or calculatmg the eth power of the accreditation and ensur- 

more secrets contained in the support. '"B ° '^is calculation and the application 

^ , , , 11-, . 1 01 the redundancy lunction to the identification number 

•nius, an Identification protocol is a dialogue, through a ^^^^^ ^^^^^ 

telecommunications network, between two entities on the is ^uch a passive identification demonstrates to the verifier 

one hand a first entity wKhing to prove its identity and which ^^^^ ^j^^j ^^ y^^^; 

can. If appropnate, be equipped with a tenninal (e.g., a ^^^^ ^^j^j^ ^ ^^^^ ^^i^j, ,^ ^ ^^^^.^ 

computer having a smart card reader) and on the other hand ^^jj^ y ^^^j^ usurpations. However, nothing pre- 

a second entity able to dialogue with the first and perform ^^^^ ^ j^,,^ ^^j^ ^^ ^ jj,^ claimant-verifier protocol 

certain verification calculations. 20 ^ dishonest verifier, from reusing for his own advantage 

The first entity, whose identity is to be verified or checked, the data supplied by the claimant, 

is hereinafter called the claimant and the second is called the Despite this fraud risk by reuse, the aforementioned 

verifier. passive identification is widely used in the banking field and 

The present invention more particularly relates to a public in the field of telecommunications or phone cards. Supple- 
key identification process, where the verifier has no need to mentary precautions (black lists, etc.) to a certain extent 
know the secrets contained in the identity module of the limit the magnitude of frauds by reuse. , 
claimant, but only non-confidential data (the public key) in However, to solve the problem of fraud by the reuse of 
order to carry out verification calculations. exchanged data and which is inherent in passive identifica- 

2. Discussion of the Background 'ion protocols, active identification protocols, i.e. requiring 

The RSA (initials of the authors RIVEST, SHAMIR, calculations on the part of the party wishing to prove 

ADLEMAN) public key cncryptation algorithm is described !<^«°'''y. have bwn proposed. These protocols not only 

in U.S. Pat. No. 4,405,829. At present, it is the most widely °f "^^A algorithm for sigmng a random 

used public key algorithm. It supplies signature diagrams I""""" P°f !^ '*^f ^"^fi"' mteractive diagrams 

also usable for identification purposes. 35 ""^"^ claimant demonstrates to the verifier that he has 

, .. ,. . . , one or more accreditations of the type defined hereinbefore 

In the RSA algonthm, a choice is made of two separate ^^^^^ accreditation or accreditations, 

prime numbers p and q and their product n is formed. A j^^^ ^^^^ ^y^j 3^^,^ diagrams are the FIAT- 

choice IS also made of an integer e which is pnme with the g^AMlR and GUILLOU-QUISQUATER diagrams respec- 

smallest common multiple of (p-1) and (q-1) (or, if desired. ^^^^^ pj^g ^ 2. The FIAT-SHAMIR identi- 

which IS prime with the product (p-l)(q-l). 40 ^^^^(.g^ ^.^^^^ ^ described in U.S. Pat. No. 4,748,668. The 

In order to encrypt a message, previously placed in digital GUILLOU and QUISQUATER identification diagram is 

form u, u being between 0 and n-1, the eth power of u is described in FR-A-2 620 248 (or its corresponding EP-A- 

calculaied in the ring of modulo n integers, i.e. v=u' mod n. 311 470 or corresponding U.S. Pat. No. 5,218,637). 

It is pointed out that the value of a modulo x integer integer These two diagrams consist of one or more iterations of 

n is equal to the remainder of the division of x by n. "5 a base variant with three passes, in which: 

For decrypting a message such as v, it is necessary to 1. the party wishing to prove identity (the claimant) 

extract the eth root of the encrypted message v in the ring of calculates the eth power modulo n of a random number 

the modulo n integers. This operation amounts to raising the r which he draws and deduces therefrom a number x, 

number v to the power d. d being the inverse of the modulo called the control and which he supplies to the verifier; 

6 exponent, the smallest common multiple of the numbers 2. the verifier draws at random a number b, called the 

(p-1) and (q-1). If the pnme factors p and q are not known, ,^ 

the determination or d is impossible and, with it, the decrypt- - , , • , , , , r » 

inn oneration claimant calculates e.g. the product of the random 

* . ' , . , ^ . ^ r number r by the blh power of his accreditation, i.e. 

One of the first practical u.ses of the RSA process for „ ^^^^ ,^ ^^^g^^_ 

Identification purposes has been the following: an authority. ^^i^^,^,^ ^3 ^^^^ ^^^^ 

responsible for the putting into place of an identification „j ^^^^ accreditation S of the claimant, he is 

system, emits a RSA-typc pubhc key, i.e. in practice the two ^j,,^ ,^ ^^^j^ consistency between x, b and y. 

numbers n and e, said key being common to the coinplete ^hcse diagrams offer a double advantage for active iden- 

system, and retams the corresponding secret elements G) and jjg^^,;^^ i^,^ ,^ ^„ 

q). In each identity module of system users, said authority insecurity level (defined as the maximum probability of 

deposits the pair constituted by: ^^^^^^ ^ defrauder) of approximately 10-^ they are 

the identification number ID of the identity module; much less costly with respect to calculation time than a RSA 

the eth rooth (or the inverse of the eth root), modulo n, of signature. On the other hand, at least in their basic version 

a number obtained from the number ID by applying to 65 are based on zero knowledge disclosure, so that exchanges 

ID a redundancy function known by everyone (whereof linked with an identification procedure cannot assist a 

an example can be found in ISO standard 9796), said defrauder in seeking secret accreditations of a user. 



01/26/2004, EAST version: 1.4.1 



6,125,445 

3 4 

Two configurations can be envisaged for implementation, equal to 3 leads to protocols which are very costly as regards 

namely on the claimant side, active identification diagrams communications. Thus, the security level of a basic 

demonstrating the possession of accreditations of the type exchange (control, question, answer) implementable under 

described hereinbefore. In a first configuration, the identity the aforementioned conditions is lower than or equal to 3 for 

module containing the accreditations has an adequate cal- 5 the GUI LLOU-QUISQUATER diagram. In order to arrive at 

culation power for performing all the calculations on this an appropriate security level (insecurity below 2'^% it is 

side. In a second configuration the identity module contain- consequently necessary to repeat the basic exchange at least 

ing the accreditations does not perform the calculations a dozen times, which leads to an increase in the number of 

itself, but instead allows them to take place in a terminal bits to be exchanged between the claimant and the verifier by 

(e.g., a microcomputer able to read the accreditations in the lO a factor of at least ten. 
identity module). 

The second configuration, although slightly less reliable SUMMARY OF THE INVENTION 

than the first, can still be useful for improving the security ^n. . r • • • ■ • , • 

r.L r a i i • ii i • i r The object of the present mvention is to obviate this 

01 the veniication OE identity modules initially designed ior , , - r .... 

r. . * u iiZ ' . disadvantage. It consists of proposmg a diagram, which is 

a passive identification. It IS necessary to have confidence in is . , i ^ . . 

the terminal used on the claimant side, but provided that said '"^^^^ ^^5="^* '° calculation time and less costly 

terminal is integrated, it is not possible for fraud to come ^^g^'ds to the number of bits exchanged, making it 

from the network or the verifier. P°^''''" to demonstrate the possession of an accreditation 

T , • 1 ' * * • corresponding to a public exponent equal to 3, without 

In the present invention, more particular interest is revealin it 

attached to the problem of use, according to the second 20 ^ 1 g 1 • 

configuration, of identity supports initially designed for a BRIEF DESCRIPTION OF THE DRAWINGS 
passive identification, in which a single accreditation cor- 
responding to a public exponent e equal to 3 has been A more complete appreciation of the invention and many 
deposited. Most French bank cards, as well as other identity of the attendant advantages thereof will be readily obtained 
supports (e.g. telecommunications cards) are of this type. 25 as the same becomes better understood by reference to the 
'The GUlLLOU-QUiSQUATER process is in theory following detailed description when considered in connec- 
usable by the terminal on the claimant side, for demonstrat- tion with the accompanying drawings, wherein: 
ing to the verifier the possession of the accreditation. In this pjc. 1 illustrates a Fiat-Shamir diagram; 
particular case the GUILLOU-QUISQUATER process 2 Ulustrates a GuiUou-Quisquater diagram; and 
comprises the following operations: 30 ...^ , . „ l mi • l 

. , i j.^.. HG.3isa flow chart illustrating the operations of the 

a) two large pnrae numbers p and q define the integer n, „^ . „^.*fi^ a- ^ *u * - 

' ^ , r . . 7 . . . , claimant and verifier according to the present invention, 
the product of p by q, the number n being rendered 

P^^'^ci DESCRIPTION OF THE INVENTION 

b) the calculation support having to prove its identity 

contains a secret accreditation S between 1 and n-l, the 35 The process according to the invention is based on the 

modulo n accreditation cube, i.e. I=S^ mod n, being following, standard security hypothesis, known as the Dififie 

rendered public Hellman hypothesis: given an integer n of adequate size, 

c) the support of the claimant is provided with means able lower than n, and two integral powers of g 
to draw at random an integer r between 1 and n-l and designated g mod n and g» mod n. it is difficult 
calculate the cube of r modulo n, called the control x: '° g"" ^od n without knowmg either a or p. 
x«r^ mod n; Under this hypothesis, the invention relates to a process 

d) the claimam transmits the control x to the verifier; ^'^r the identification of a support, called "the claimant", by 

e) the verifier draws at random an integer b lower than the ^^"^^ ^J"" verifier", said support and saM means 
exponent 3, i.e. equal to 0, 1 or 2, said integer being ^^^^Pf ^ appropriate calculation and storage 
called the question; means, the claimant and verifier having in common: 

0 the verifier transmits the question to the claimant; ^ ^^^^ ^^^^f ^ \ ^^ich is the product of two prime 

g) the claimant calculates the number y defined by: yorS* numbers (p, q), 

mod n; ^ second integer g between 0 and n-l and of high order 

h) the claimant transmits the number y to the verifier; 50 ^ ^"^^ ^ ^^^^^^ ^ 

i) the verifier raises to the cube the number y and ^^^^ ^^^^ "^^^ 

calculates the product of the control x (which has been ^ parameter m detemiming the interval [0, m-1] in which 

transmitted to him) by the power b of I (b drawn by him ^^^"^^ random exponents, 

and I which is public), the verifier then comparing y^ a first and second separate hash functions H^, and 

and xl* mod n — if consistency arises, the claimant has 55 which are independent of one another, 

correctly replied to the question and his authenticity is the claimant also having a secret number S equal to the 

assumed. modulo n cubic root of a number I deduced from his identity. 

The security of such a diagram is based on the very so that the number S verifying: S^=I mod n, wherein the 

hypo thesis of the RS A diagram. As both the integer n and the claimant and verifier utilize their calculation and storage 

exponent 3 are public, it is difficult for a third party 60 means for performing the following, successive operations: 

defrauder, to arrive at r by taking the cubic root of x, without phase A: the claimant: 

knowing the factors p and q, whereof n is the product. Aa) draws at random a first integral exponent a 

Without the knowledge of r, the defrauder cannot correctly between 0 and m-1, 

reply to the question posed by the verifier. Ab) calculates a number r equal to the power a of the 

For such a process, as well as for other hitherto known 65 modulo n number g, namely r«g" mod n, 

identification diagrams, the situation where there is only a Ac) calculates a number R equal to the cube of r 

single accreditation corresponding to a public exponent modulo n, namely: R-r^ mod n-g^° mod n. 
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Ad) transmits the number R to the verifier; 
phase B: the verifier: 

Ba) draws at random a second integral exponent p 

between 0 and m-1, 
Bb) calculates a number t equal to the power p of the 

g modulo n number,namely: tog^ mod n, 
Be) calculates a number T equal to the cube of t modulo 

n, namely: T=t^ mod n=g^^ mod n, 
Bd) calculates a number Z equal to the power p of R 

modulo n, namely: Z«R^ mod n, 
Be) applies the first hash function to Z for obtaining 

a number h: h=H3(Z), 
BQ transmits to the claimant the numbers T and h; 
phase C: the claimant: 

Ca) calculates a number Y equal to the power a of the 

number T modulo n, namely: Y=T" mod n, 
Cb) applies to the number Y the first hash function 

and obtains the result H_i(Y) and verifies whether this 

result is equal to the number h received from the 

verifier, 

Cc) applies to the number Y the second hash function 
H2 for obtaining a result H: H^HjOO, 

Cd) calculates a number z equal to the product of the 
number r by the secret S modulo n, namely: z=rS 
mod n, 

Ce) transmits the numbers z and H to the verifier; 
phase D: the verifier: 

Da) applies to the number Z the second hash function 
H2 and verifies whether the result obtained H2(Z) is 
equal to the number H received from the claimant, 
Db) calculates, on the one hand, the product of R by I 
modulo n and, on the other hand, the cube of z 
modulo n and checks whether the two results are 
equal, the identification of the claimant by the veri- 
fier being made if the three verifications Cb) Da) Db) 
are performed. 
The parameter m, which the claimant and verifier have in 
common, can be chosen with the same order of magnitude 
as k, or equal to n. The value of m must not reveal that of 
k, which is not known either to the claimant or to the verifier. 

The following table summarizes the different operations. 
Note, FIG. 3 is a flow chart illustrating the same operations. 

The horizontal band marked 0 indicates the data known 
by both entities, namely on the one hand, the number n, 
number g and cube of the secret I and, on the other hand, the 
two hash functions and H2. 

TABLE 1 



TABLE 1-continued 



Claimant 



Verifier 



Hi. 

a < m 

r o g° mod n 

R o P = - mod n 



p < m 



n, g, I 
Hi. H2 



t " mod n 

T - - g^P mod n 

Z - RP mod n 



T. h h - H,(Z) 



Y - mod n 



Claimant 



Verifier 



10 



h=HiCY) 

2 - rS mod 

? 

H = Il2(Z) 



z, H 



= RI mod n 



The horizontal band A gives the first operations performed 
by the claimant (operations Aa to Ad in the above 
definition). 

20 The horizontal band B gives the following operations 
performed by the verifier (operations Ba to BQ. 

The horizontal band C gives the operations again per- 
formed by the claimant (operations Ca to Ce). 

Finally, the horizontal band D gives the two final opera- 
25 tions performed by the verifier. 

Such a process makes it possible to check the authenticity 
of the holder of an accreditation. Thus, if the claimant knows 
the secret S, he can correctly reply to the questions asked by 
the verifier, because he can calculate the quantity z=rS mod 
30 n- 

Conversely, in order to be accepted, the claimant must 
ensure that the equation H«H2(Z) is satisfied and, for this 
purpose, after supplying R to the verifier and receiving 
T=g^^ mod n, he must be able to supply a number H, such 
35 that H=H2(R^): 

1, either H is not calculated with the aid of the hash 
function Hj, then, by admitting that can be modelled 
as a random function, there is a negligible probability 
of relation H=H2(R^) is satisfied; 
40 2. or H is the result of on a value Y, then (unless there 
is a collision of H^) Y is equal to Z, in which case, on 
the basis of T=g^^ the claimant is able to calculate 
T"=g^"^ and then, on the basis of the starting 
hypothesis, he knows such that R=g^" mod n. 
45 In addition, the claimant must supply a number z, so that 
the relation z^«RI mod n is satisfied. For this purpose, he 
must supply a cubic root of RI, such that RI=g^**l mod n, 
then I=(zg-'')^ mod n. 

It is also possible to prove, by means of a few supple - 
50 mentary hypotheses of a not very restrictive nature, that a 
defrauder using all imaginable fraudulent procedures cannot 
obtain any information on the accreditation of the claimant 
and consequently usurp his identity. 

Thus, assuming that said defrauder interrogates the claim- 
55 ant (passing himself off as the verifier) with a view to 
extracting from him an information on the accreditation S: 
a) when confronted with an honest claimant, the defrauder 
is obliged to ask questions honestly and to satisfy the 
equation h=H;i(Y), after receiving R=g^", he must 
60 supply T and h, such that h=H3(T"): 

1. either h is not calculated with the aid of H^, then, by 
admitting that can be modelled as a random 
function, there is a negligible satisfaction probabil- 
ity; 

65 2. or h is the resuh of Hj on a value Z, then, unless there 
is a collision of H^, we obtain Y=Z and in this case, 
on the basis of R«g^", the verifier is able to calculate 
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X^og^^P and on the basis of the starting hypothesis, 

he knows p such that T«g^^ mod n; 
b) in the case where the secret S can be expressed as an 
integral power g'' of g and where the value of m is close 
to a multiple of k, it is possible to simulate the claimant ^ 
without knowing the secret S, which means that the 
interactions which the defrauder can have with the 
claimant will not enable him to learn anything about S 
and the simulator will then perform the following 
operations: 20 

1. he chooses a number 6 below m, 

2. he calculates z=g* mod n, z^=g^^ mod n and K^z^\~\ 
i.e. g^t^*'^ mod n, (the numbers R and z formed in 
this way roughly follow the same distribution as 
Rog^" and z=g""^, 35 

3. he supplies R to the verifier, who returns T and h — as 
shown hereinbefore, the verifier is necessarily 
honest, which means that he knows p such that 
T=g^^ mod n and can consequently have knowledge 
of P (then T^g"*^ mod n, Z=R^ mod n and h=Hj(Z)), 20 

4. he calculates Y=R^=Z mod n and H-H2(Y), 

5. he supplies (z,H) to the verifier. 
Therefore the above -defined process is reliable and 

secure, even when confronted with active attacks. 

What is claimed is: 25 
1. A process for an identification of a calculation and 
storage means claimant by a verifier, the claimant and 
verifier having calculation and storage mechanisms, 

wherein the claimant and verifier have the following in 
common: ■'^ 
a first integer n, which is the product of two prime 

numbers (p, q), 
a second integer g between 0 and n-1 and of high order 

k, the order k being defined as the smaller of the 

numbers such that g*=l mod n, 
a parameter m determining the interval in which are 

drawn the random exponents, 
first and second separate hash functions H^, H2 and 

which are independent of one another, 
wherein the claimant further includes a secret number S 
equal to the modulo n cubic root of a number I deduced 
from its identity, so that the number S verifies: S^-I 
mod n, 

wherein the claimant and verifier utilize their calculation 45 
and storage mechanisms for performing the following, 
successive operations: 
phase A: the claimant: 



8 

Aa) draws at random a first integral exponent a 

between 0 and m-1, 
Ab) calculates a number r equal to the power a of the 

modulo n number g, namely; r=g" mod n, 
Ac) calculates a number R equal to the cube of r 
modulo n, namely: R=r^ mod n«g^ mod n, and 
Ad) transmits the number R to the verifier; 
phase B: the verifier: 

Ba) draws at random a second integral exponent p 

between 0 and m-1, 
Bb) calculates a number t equal to the power p of the 

g modulo n number, namely: t«g^ mod n. 
Be) calculates a number T equal to the cube of t 

modulo n, namely: T=l^ mod n=g^^ mod n, 
Bd) calculates a number Z equal to the power p of R 

modulo n, namely: Z=R^ mod n. 
Be) applies the first hash function to Z for 

obtaining a number h; h=Hi(Z), and 
Bf) transmits to the claimant the numbers T and h; 
phase C: the claimant: 

Ca) calculates a number Y equal to the power a of 

the number T modulo n, namely: Y«T" mod n, 
Cb) applies to the number Y the first hash function 
Hj and obtains the result H^(Y) and verifies 
whether this result is equal to the number h 
received firom the verifier, 
Cc) applies to the number Y the second hash function 

H2 for obtaining a result H: H=H2(Y), 
Cd) calculates a number z equal to the product of the 
number r by the secret S modulo n, namely: z=rS 
mod n, and 

Ce) transmits the numbers z and H to the verifier; 
phase D: the verifier: 

Da) applies to the number Z the second hash function 
H2 and verifies whether the result obtained H2(Z) 
is equal to the number H received from the 
claimant, namely: H=H2(Z) and mod n=RI 
mod n, and 

Db) calculates the product of R by I modulo n and 
the cube of z modulo n and checks whether the 
two results are equal, and 
wherein the identification of the claimant by the verifier is 
made if the three verifications determined in steps Cb), 
Da), and Db) are performed. 
2. The process according to claim 1, wherein the claimant 
is a smart card. 

♦ * * 4c * 
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ABSTRACT 



A communication method between a first and second party, 
in the presence of a trusted party, that enables a transaction 
in which the second party receives a first value produced by 
the first party and unpredictable to the second party if and 
only if the first party receives a second value produced by 
the second party and unpredictable to the first party. The 
method includes two basic steps: exchanging a first set of 
communications between the first and second parties with- 
out participation of the trusted party to attempt completion 
of the transaction, and if the transaction is not completed 
using the first set of communications between the first and 
second parties, having the trusted party take action to 
complete the transaction. 
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SIMULTANEOUS ELECTRONIC 
TRANSACTIONS 

This application is a continuation of U.S. patent appli- 
cation Ser. No. 08/751,217, filed Nov. 18, 1996, now U.S. 
Pat. No. 5,666,420, 

TECHNICAL FIELD 

The present invention relates generally to electronic com- 
merce and transactions and more particularly to techniques 
for enabhng users to effect certified mail, contract signing 
and other electronic notarization functions. 

BACKGROUND OF THE INVENTION 

The value of many transactions depends crucially on their 
simultaneity. Indeed, simultaneity may be so important to 
certain financial transactions that entities often are willing to 
incur great inconvenience and expense to achieve it. For 
example, consider the situation where two parties have 
negotiated an important contract that they now intend to 
"close." Often, the parties find it necessary to sign the 
document simultaneously, and thus they meet in the same 
place to watch each other's actions. Another example is the 
process of certified mail, where ideally the sender of a 
message desires that the recipient get the message simulta- 
neously with the sender's obtaining a "receipt". A common 
certified mail procedure requires a person who delivers the 
mail to personally reach the recipient and obtain a signed 
acknowledgement when the message is delivered. TOs 
acknowledgement is then shipped to the sender. Again, this 
practice is costly and time consuming. Moreover, such 
acknowledgements do not indicate the content of the mes- 
sage. 

In recent years, the cost, efficiency and convenience of 
many transactions have been improved tremendously by the 
availability of electronic networks, such as computer, 
telephone, fax, broadcasting and others. Yet more recently, 
digital signatures and public-key encryption have added 
much needed security to these electronic networks, making 
such communication channels particularly suitable for 
financial transactions. Nevertheless, while electronic com- 
munications provide speed, they do not address simultaneity. 

The absence of simultaneity from electronic transactions 
severally limits electronic commerce. In particular, hereto- 
fore there has been no effective way of building so-called 
simultaneous electronic transactions ("SET's"). As used 
herein, a SET is an electronic transaction that is simulta- 
neous at least in a "logically equivalent" way, namely it is 
guaranteed that certain actions will take place if and only if 
certain other actions take place. One desirable SET would be 
certified mail, however, the prior art has not addressed this 
problem effectively. This can be seen by the following 
consideration of a hypothetical example, called extended 
certified mail or "ECM". 

In an ECM transaction, there is a sender, Alice, who 
wishes to deliver a given message to an intended recipient. 
Bob. This delivery should satisfy three main properties. 
First, if Bob refuses to receive the message (preferably 
before learning it), then Alice should not gel any receipt. 
Second, if Bob wishes to receive the message, then he will 
receive it and Alice will get a receipt for the message. Third, 
Alice's receipt should not be "generic," but closely related 
to the message itself. Simultaneity is important in this 
transaction. For instance, Alice's message could be an 
electronic payment to Bob, and it is desired that she obtains 
a simultaneous receipt if possible. 
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Alice could try to get a receipt from Bob of a message in 
in the following way. Clearly, sending m to Bob in the clear 
as her first communication does not work. Should this 
message be her digital signature of an electronic payment, a 

5 malicious Bob may loose any interest in continuing the 
conversation so as to deprive Alice of her receipt. On the 
other hand, asking Bob to send first a "blind" receipt may not 
be acceptable to him. 

Another alternative is that Alice first sends Bob an 

^0 encryption of m. Second, Bob sends Alice his digital sig- 
nature of this ciphertext as an "intermediate" receipt. Third, 
Alice sends him the decryption key. Fourth, Bob sends Alice 
a receipt for this key. Unfortunately, even this transaction is 
not secure, because Bob, after learning the message when 

^5 receiving Alice's key, may refuse to send her any receipt. 
(On the other hand, one cannot consider Bob's signature of 
the encrypted message as a valid receipt, because Alice may 
never send him the decryption key.) 

These problems do not disappear by simply adding a few 
more rounds of communication, typically consisting of 
"acknowledgements". Usually, such additional rounds make 
it more difficult to see where the lack of simuUaneity lies, but 
they do not solve the problems. 

Various cryptographic approaches exist in the literature 
that attempt to solve similar problems, but they are not 
satisfactory in many respects. Some of these methods appli- 
cable to multi -party scenarios propose use of verifiable 
secret sharing (see, for example, Chor et al), or multi-party 
protocols (as envisioned by Goldreich et al) for making 
simultaneous some specific transactions between parties. 
Unfortunately, these methods require a plurality of parties, 
the majority of which are honest. Thus, they do not envision 
simultaneous transactions involving only two parties. 
Indeed, if the majority of two parties are honest then both 
parties are honest, and thus simultaneity would not be a 
problem. Moreover, even in a multi -party situation, the 
complexity of these prior art methods and their amount and 
type of communication (typically, they use several rounds of 
broadcasting), make them generally impractical. 

Sophisticated cryptographic transactions between just two 
parties have been developed but these also are not simulta- 
neous. Indeed, if just two people send each other strings 
back and forth, and each one of them expects to compute his 

^5 own result from this conversation, the first to obtain the 
desired result may stop all communications, thereby depriv- 
ing the other of his or her result. Nonetheless, attempts at 
providing simultaneity for two-party transactions have been 
made, but by using assumptions or methods that are unsat- 

5Q isfactory in various ways. 

For example, Blum describes transactions that include 
contract signing and extended certified mail and that relies 
on the two parties having roughly equal computing power or 
knowledge of algorithms. These assumptions, however, do 

55 not always hold and arc hard to check or enforce anyway. In 
addition, others have discovered ways to attack this rather 
complex method. A similar approach to simultaneity has 
also been proposed by Even Goldreich and Lempel. In 
another Blum method for achieving simultaneous certified 

60 mail, Alice does not know whether she got a valid receipt. 
She must go to court to determine this, and this is undesir- 
able as well. 

A method of Luby et al allows two parties to exchange the 
decryption of two given ciphertexts in a special way, namely, 
65 for both parties the probability that one has to guess cor- 
rectly the cleartexl of the other is slowly increased towards 
100%. This method, however, does not enable the parties to 
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achieve guaranteed simultaneity if one party learns the 
cleariext of the other's ciphertext with absolute probability 
(e.g., by obtaining the decryption key); then he can deny the 
other a similar success. 

For this reasons several researchers have tried to make 5 
simultaneous two-party transactions via the help of one or 
more external entities, often referred to as "centers", "serv- 
ers" or "trustees", a notion that appears in a variety of 
cryptographic contexts (see, for instance, Needham and 
Schroder and Shamir). A method for simultaneous contract 30 
signing and other transactions involving one trustee (called 
a "judge") has been proposed by Ben-Or et al. Their method 
relies on an external entity only if one party acts dishonestly, 
but it does not provide guaranteed simultaneity. In that 
technique, an honest party is not guaranteed to have a signed ^5 
contract, even with the help of the external entity. Ben-Or et 
al only guarantee that the probability that one parly gels a 
signed contract while the other does not is small. The smaller 
this probability, the more the parties must exchange mes- 
sages back and forth. In still another method, Rabin envi- 20 
sions transactions with the help of external party that is 
active at all times (even when no transaction is going on), 
but also this method does not provide guaranteed simulta- 
neity. 

The prior art also suggests abstractly that if one could 
construct a true simultaneous transaction (e.g., extended 
certified mail), then the solution thereto might also be useful 
for constructing other types of electronic transactions (e.g., 
contract signing). As noted above, however, the art lacks an 
adequate teaching of how to construct an adequate simul- 
taneous transaction 

There has thus been a long-felt need in the art to overcome 
these and other problems associated with electronic trans- 
actions. 

35 

BRIEF SUMMARY OF THE INVENTION 

It is an object of the invention to provide true simulta- 
neous electronic transactions. 

It is a further object of the invention to provide an 4q 
electronic transaction having guaranteed simultaneity in a 
two-party scenario and with minimal reliance and support of 
a third party. 

It is another more specific object of the invention to 
provide simultaneous electronic transactions between two 45 
parlies that rely on third parties in a minimal and convenient 
manner. In particular, it is desired to provide electronic 
transactions between two parties that guarantee simultaneity 
via the help of an invisible third party. A third party is said 
to be "invisible" because it does not need not to take any 50 
action if the transaction occurs with the parties following 
certain prescribed instructions. Only if one of the original 
parties deviates from these instructions may the other invoke 
the intervention of the up-lo-then invisible third party, who 
then can still guarantee the simultaneity of the transaction 55 
even though it has not participated from its inception. 

These and other objects are provided in a communication 
method between a first and second party, in the presence of 
a trusted parly, that enables a transaction in which the second 
party receives a first value produced by the first parly and 60 
unpredictable to the second party if and only if the first parly 
receives a second value produced by the second party and 
unpredictable to the first parly. The method includes two 
basic steps: exchanging a first set of communications 
between the first and second parties without participation of 65 
the trusted party to attempt completion of the transaction, 
and if the transaction is not completed using the first set of 
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communications between the first and second parlies, having 
the trusted parly take action to complete the transaction. 

Where the first party's value is a message and the second 
party's value is a receipt, the transaction is a certified 
transmission of the first parly's message. Alternatively, the 
first party's value represents a commitment to a contract and 
the second parly's value represents a commitment to the 
contract, such that the transaction is a contract closing. 

Preferably, according to the method the first party can 
prove that some information it receives is the second value, 
and the second party can prove that some information it 
receives is the first value. 

According to the more specific aspects of the method, at 
least one of the first and second parties and the trusted party 
can encrypt messages, and at least one of the first and second 
parties and the trusted party can decrypt messages. The first 
set of communications includes at least one communication 
of the first party to the second party of a data string generated 
by a process including encrypting a second data string with 
an encryption key of the trusted party. The second data string 
includes a ciphertext generated with an encryption key of 
one of the parties, as well as information specifying or 
identifying at least one of the parties. The first set of 
communications also includes at least one communication of 
the second party of a data string generated by a process that 
includes having the second party digitally sign a data string 
computed from information received from the first party in 
a prior communication, wherein the data string generated by 
the second party is the second party's value. 

According to further aspects of the method, if the second 
party does not get the first value in the first set of 
communications, the second party sends the trusted party, 
for further processing, a data string that includes al least part 
of the data received from the first party. The further pro- 
cessing by the trusted party includes decrypting a ciphertext 
with a secret decryption key. The trusted party then sends the 
first party information that enables the first party to compute 
the second value, and the trusted party sends the second 
party information that enables the second parly to compute 
the first value. In either case, the trusted party also verifies 
identity information of al least one of the parties but pref- 
erably does not learn the first value. 

DETAILED DESCRIPTION OF THE DRAWINGS 

For a more complete understanding of the present inven- 
tion and Ihe advantages thereof, reference should be made to 
the following Detailed Description in conjunction with the 
accompanying drawings in which: 

FIG. 1 illustrates a preferred embodiment of the present 
invention in which a transaction between a sender and a 
recipient is completed without involvement of a trusted 
parly; 

FIG. 2 shows the case where the recipient proceeds 
directly to the trusted party for resolution without providing 
a receipt for the message to the sender; 

FIG. 3 shows the case where the sender does not provide 
the recipient with a form of the message readable to the 
recipient after receiving the message receipt; and 

FIG. 4 shows the case where the sender does not provide 
the recipient with a readable form of the same message 
included in its original transmission. 

DETAILED DESCRIPTION 

In each of the schemes described below, there is a user 
Alice and a user Bob. The "invisible" third party may be a 
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financial center that facilitates SETs among its customers, will be executed, and in this order. Step B2 will be executed 

including Alice and Bob. For convenience, the following only if Alice fails to execute Step A2 properly (the case 

description shows how to make extended certified mail shown in FIGS. 2 and 3). The execution of Step B2 causes 

"simultaneous", although the invention is not so limited. In the Post OfEce to execute its only step, PO (for clarity, 
the context of an ECM system, the third party is called the 5 shown as two steps, POla and POlb in the Figures). The 

Post OfiBce. As will be seen, however, contrary to ordinary protocol is as follows: 
certified mail, the Post Office here is invisible. The inventive 
scheme is also preferable to ordinary certified mail because 

the message receipt also guarantees the content of the 7"- u ai- ! ^"TTT 

° =*. . . _ Al, Given her message m, Alice computes z o Epo(( A, B, 

message. Also, the electronic transaction is faster, more lO Eni^))), the encryption in the Post Office public key of 

informative and more convenient than traditional certified a triplet consisting of identifiers a, b and the message 

mail, and its cost should be substantially lower. encrypted in Bob's key, and then sends z to Bob. 

- , , Bl. Upon receiving z from Alice, Bob digitally signs it and 

In the preferred embodiment, an extended certified mail sends it to Alice as the receipt, 

system is provided using a single "invisible" trustee or A2. If Alice receives the properly signed receipt from Bob, 

"trusted" party. The system is implemented in a computer ^5 she sends m to Bob. 

network, although i. should be reaUzed that telephone, fax, 'i^^ 

broadcast or other communication networks may be used. E^{m))) o z, the value originally received from Alice, 

Thus, without limitation, it is assumed that each user in the then he outputs m as the message and halts (the case of FIG. 1). 

system has a computer capable of sending and receiving Otherwise, Bob sends the value z signed by him to the Post OflScc 

«^ p,^™ ^*u^^ ^ ™ in indicating that Alice is the sender and he is the recipient. 

messages to ana rrom other computers via proper commu- ir n u. • * i . • . .i. n . 

. ^ ^ r r PO, If Bob s signature relative to z is correct, the Post 

nication channels. Office decrypts z with its secret key. If the result is 

Each user in the system has a unique identifier. Alice's ^ ^"P^^' consisting of A, B and a string x, the Post 

identifier is denoted by A, and Bob's identifier is B. The ""^^T ''p 1! ' ''^'''^ 

. , _ rt~ > receipt, and (b) sends x to Bob. 

identifier of the Post OfBce is denoted by PO. Users and the 

Post OfiBce can digitally sign messages. Thus, each has a 

secretsigningkey and a matching public verification key. If Preferably, in step Al Alice sends z to Bob digitally 

m is a message (string), then SIG^(m) indicates Alice's signed by her. In addition, in step Al Alice may sign z in a 

signature of ra. (It is assumed, for convenience, that m is standard format that indicates z is part of an extended 

always retrievable from its signature. This is the case for ^^^J" ^.^^^ ^-8 ' ^^g" 

most signature schemes, and it is otherwise possible to niple (ECM, A, B, z). In this way Bob is certain that z comes 

consider a signed message as the pair consisting of the Al^^e and that, when Alice holds a receipt for m signed 

message and its signature ) f.^^ ^!^P .^-V have a certified version of m. 

^ , ir- Further, if z is digitally signed by Alice in step Al, Bob first 

Users and the Post OfiBce can encrypt messages by means checks Alice's signature, and then countersigns z himself in 

of a public-key encryption algorithm (e.g., RSA). Thus, each step Bl. The adoption of a standard format also insures that, 

has a public encryption key and a corresponding secret by signing z in step Bl as part of an ECM system, Bob does 

decryption key. E^(m), E^(m), and Epoi^) denote, not sign accidently a message that has been prepared by 

respectively, the encryption of a message m with the public Alice maliciously. Also, the Post OfiBce may also check 

key of Alice, Bob, and the Post OfBce. For simplicity, it is Alice's signature or any additional formats if these are used, 

assumed that these schemes are secure in the sense that each In analyzing the protocol, it should be noted that Alice, 

of E^, Ej5, and Ep^ appear to behave as a random function. given Bob's signature of z as receipt in step Bl, can prove 

The system can be suitably modified if these functions are the content of the message by releasing m. Indeed, all can 

much less secure. compute x« B^im) and then verify that Ep^((A, B, x))»z. 

Again, for simplicity these encryption algorithms are Notice also that the Post OfiBce does not understand the 
deterministic and uniquely decodable. Thus, given a value y 45 message sent in step B2 via the ECM protocol, whether or 

and a message m, all can verify whether y is the encryption not it is called into action. Rather, the Post OfiBce can only 

of m with, for example, the Post OfiBce 's key, by checking obtain E^(m), but never m in the clear (in this embodiment), 

whether Epo{m) equals y. (If the encryption scheme is Third, notice that m is, by definition, equal to E'^x), 

probabilistic, then one may convince another that a string y where (A, B, x)=Epc>"\z), and may be non-sensical. Indeed, 
is an encryption of a message by providing m together with 50 nothing prevents Alice firom sending Bob a garbled message 

the random bits that were used to encrypt m.) If y is a in step Al. However, she can only get a receipt for this same 

ciphertext generated by means of the encryption algorithm garbled message in step Bl. It is also noted that, if not every 

E, E"\y) denotes the corresponding cleartext, whether or string is an encryption of some message, Alice may choose 

not E defines a permutation. (It may also be possible to use z so that it is not the encryption of anything. In such case, 
encryption algorithms that are not uniquely decodable, for 55 however, she cannot ever claim to have a receipt for any 

instance, if it is hard to decrypt a given ciphertext in two message. Alternatively, it may be desirable to use crypto - 

difiEcrent ways.) For simplicity, messages arc encrypted systems for which either every string is an encryption of 

directly with a public-key algorithm, however, one could some other string or such that it can be easily detected 

first encrypt a message conventionally with some key k, and whether y encrypts something. 

then encrypt k with a public-key algorithm. (Thus, to go The protocol works for the following reasons. When 

decrypt m, one need only just decrypt k). receiving the value zoEpo((A, B, E^im))) from Alice in step 

In one preferred embodiment shown in FIGS. 1-4 and Al, Bob will have difiSculty in computing E^m), and thus 

outlined below, the ECM method requires 5 possible steps of m, from z without the Post OflSce's secret key. Thus, if he 

communication: Al and A2 for user Alice, Bl and B2 for halts, Alice would not get her receipt, but Bob would not get 
user Bob, and PO for the Post OfiBce. However, at most 3 65 m either. 

steps should have to be executed. If Alice and Bob are both Assume now that Bob signs z and sends it to Alice (step 

honest (the case .shown in FIG. 1), only steps Al, Bl, and A2 Bl). Becau.se this gives Alice a valid receipt from Bob for 
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her message m, for the simultaneity constraint to hold, it 
must be shown thai Bob easily obtains m. This is certainly 
true if Alice sends m to Bob in Step Al. Assume therefore 
that Alice does not send him m as shown in FIG. 4. Then, 
Bob presents z signed by him to the Post Office, essentially 5 
asking the Post 0G5ce to retrieve (for him) E^(m) from z as 
shown in FIG. 3. The Post Office complies with this request. 
In doing so (step ?01b), however, the Post Office also sends 
Alice z signed by Bob as the receipt (step POla). It does so 
to prevent one last possibility; that Bob, upon receiving z 
from Alice in Step Al, rather than sending her the receipt in 
Step Bl, goes directly to the Post OIEce in order to have 
£b(^) extracted from z, 'Ms is the case shown in FIG. 2. 

Summarizing, if Alice sends a message encrypted with the 
Post OCQce key to Bob, and Bob does not send Alice a 
receipt, or if he does not access the Post Office, Bob will 
never learn m. Otherwise, Alice is guaranteed to get her 
receipt for m either from Bob or from the Post Office. On the 
other hand, upon receiving an encrypted message. Bob is 
guaranteed that he will understand it, either helped by Alice 20 
or helped by the Post Office. 

In the preferred embodiment above, the triplet (which 
includes the ciphertext E^(m)) also includes A and B. The 
ciphertext is customized in this way so that it can be used by 
the system only for the purpose of Alice sending a message 25 
to Bob. Whether or not this customization is performed, the 
system is very convenient to use because everyone knows 
the public key of the Post Office, because everyone can 
encrypt a value with that key, and because the Post Office 
can remove this encryption layer for those recipients who 30 
claim to have been betrayed by their senders. However, 
without the above (or an equivalent) customization, this 
same convenience could be exploited by a malicious 
recipient, who could learn his messages while denying the 
senders their legitimate receipts. 35 

In particular, assume that this customization is removed 
altogether. Then, a malicious Bob, upon receiving z'=Ep^ 
(E^(m)) — rather than z^Epoii^ B, E^(m))) — from Alice in 
Step Al, may behave as follows. First, he does not send 
Alice any receipt. Second, he signs z'. Third, he gives this 40 
signed value to the Post Office complaining that a sender 
Chris (an accomplice of his) is refusing to send him the 
message in the clear. At this point, the Post Office, after 
verifying Bob's signature and not having any way of check- 
ing whether Chris is the real sender, retrieves E^(m) from z' 45 
and sends Ej^m) to Bob, while simultaneously sending the 
signed z' to Chris as his receipt. Of course, Chris may 
destroy or hide this receipt. Meanwhile Alice, who does not 
get any receipt after Step Al, may think that Bob is away or 
does not want to receive her message. But she believes that 50 
Bob will never be able to read her message in any case. 

'This violation of the simultaneity constraint (i.e.. Bob 
receiving m while Alice having no receipt) may still occur 
if, without any customization, Alice signs z when sending it 
to Bob in Step Al. Indeed, Bob would have no trouble in ss 
removing Alice's signature, asking Chris to sign z' and then 
presenting to the Post Office z' signed by Chris and coun- 
tersigned by himself. The Post Office, after verifying Bob's 
and Chris's signatures, would still (after removing its 
encryption layer) send E^im) to Bob and the receipt to Chris. 60 
This violation of simultaneity, however, does not occur with 
the customization of the triplet to include A and B. Indeed, 
assume that Bob gives the Post Office the value z«E^^((A, 
B, E^(ra))) originally received by Alice and signed by him 
and Chris, claiming that it was sent to him by Chris. Then, 65 
the Post Office, after verifying Bob's (and Chris's) signature 
and after computing the value Ep^'^z), will notice that this 
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value — i.e. (A, B, Efj(m)) — does not specify Chris to be the 
sender and Bob the receiver. 

The benefits of this customization may be implemented in 
varying ways. For instance, Alice's signature of (B,E5(m)) 
may be sufficient to indicate that the sender is Alice and the 
receiver is Bob. More generally, any customization that 
prevents Bob from obtaining E^m) from the Post Office 
while convincing the Post Office not to send Alice the receipt 
is within the scope of the invention. 

It should be realized that any customization for the 
purpose of simultaneous electronic transactions is itself 
within the scope of the present invention, whether or not 
implemented with an invisible third party. For instance, 
Alice may send Epo(A,B,EB(m)) directly to the Post Office, 
which gives E^m) to Bob (if Bob signs the receipt for Alice) 
after checking that Alice and Bob are, respectively, the 
sender and the receiver. Alternatively, Alice may send the 
Post Office Epo(SIG^(B,E^m))) for identifying the sender 
and the recipient in a way that cannot be decoupled from the 
transaction. Such approaches may be especially useful with 
a plurality of trustees as described below. Such an approach, 
which calls into action the trusted party directly with a 
proper customization step as described, is also useful for 
hiding the identity of the sender from the recipient. Indeed, 
the Post Office may solicit a proper receipt from Bob without 
disclosing Alice's identity (even if the receipt indicates the 
content of Alice's message). 

Although not specified above explicitly, it should be 
appreciated that all or part of the actions required by the Post 
Office, Alice or Bob can be realized in software. Some of 
these actions can also be perfonmed by hardware, or physi- 
cally secure devices (i.e. devices such as secure chips having 
at least some portion of which is tamper-proof). 

Many variations of the disclosed protocol can be envi- 
sioned and are within the scope of the present invention. For 
instance, while the "receipt" described above witnesses the 
content of the message sent, the receipt can be made generic, 
e.g., by having Bob sign a "declaration" (instead of a string 
including an encrypted version of the message) that he has 
received an encrypted message from Alice at a given time. 
Also, if desired, the customization step (i.e. the inclusion of 
the identifiers A and B in the triplet) can be omitted. This 
might be advantageous, for example, when no other user 
may collude with either Alice or Bob to disrupt simultaneity. 
This may occur where there is no third user, as in the case 
when certified mail occurs between two predetermined 
people. In the disclosed system, the Post Office cannot learn 
the content of the message, but such a restriction can be 
removed also (e.g., by having Alice compute z=Epc>(A, B, 
m)). It may also be convenient to one-way hash strings prior 
to signing them. 

Still another variation would be to impose some temporal 
element on the transaction. For instance, when Alice sends 
Bob z=Ep^(A, B, Es(m)\ she may sign z together with some 
additional information that specifies a certain time (either 
absolute or relative to the sending time) after which the Post 
Office will not help Bob obtain the message. Preferably, 
Alice specifies this time in a signed manner both outside the 
Post Office encryption layer as well as within the triplet. In 
such case, the Post Office must obtain from Bob all neces- 
sary information to verify that the time specified outside the 
PO encryption layer checks with the time specified within 
the triplet. If it does not, then several possibilities may occur. 
For example, the Post Office will not help Bob recover the 
message, or the message is considered unsent (even if Alice 
obtains a receipt). 
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Other variations are also possible. Some variations may enable Bob to get his message and Alice to gel her receipt, 

be used in conjunction or in alternative to the techniques without sending messages back and forth, this goal can be 

described above. One group of such variants concerns the accomplished by means of a more complex dialogue, 

encryption method used. Indeed, more elaborate dialogues, and in particular zero 

For instance, docs not need to be interpreted as an 5 knowledge proofs (see, e.g., Goldwasser et al or Goldreich 

encryption algorithm for which Bob has the decryption key. ct al) could be useful (also as an alternative to physically 

It may just be an encryption algorithm for which Bob can secure devices) to give Bob the message or Alice the receipt 

have the message decrypted. For example, and without so that they learn their respective values, but are not able to 

limitation, the decryption key of may lie with a group of "prove" these values to third parties, 
people, each having a piece of the key. These same alter- ^0 A further alternative method envisions a Post OfBce with 

native interpretations apply also to E^ or £po- a plurality of trustees, A multiplicity of trustees can be 

Also, while public-key cryptosystems are quite beneficial for various aspects, particulariy, if the system is 

convenient, it should be realized that conventional crypto- set up so that more than one of the trustees must collude for 

systems could be used for the ECU protocol. For example, cheating to occur. Presumably, however, each trustee is 

X may be the conventional encryption of (A, B,E5(m)) with selected with trustworthiness (or, if it is a device, proper 

a secret key k shared between Alice and the Post Ofiace. This functioning) as a criterion, and thus the possibility that more 

key k may be released if it is desired that Bob verify m to than one of them is malicious or defective is very small, 

be the genuine message. If, however, it is feared that release A simultaneous ECM system with a multiplicity of trust- 

of a different key may change the content of the messages, ees may make novel use of prior techniques such as fair 

special redundancies could be used. For instance, conven- cryptography, or secret sharing, verifiable secret sharing or 

tionally a message M is encrypted by actually encrypting threshold cryptosystems, 

(M, H(M)), where R is a one-way function. Thus, if e is an In a construction based on fair public cryptosystems, the 

encryption of (M, H(M)) with a key k, it is hard to find a triplets (A, B, E^(m)) are not encrypted with the Post 

second key K such that e also is an encryption with that key Office's public key, but rather with a user public key. In this 

of (M'H(M')). It is preferable that k, rather than being a embodiment, user Alice computes a pair of public and secret 

secret key shared by Alice and the Post Office, is a temporary key of a fair public-key cryptosystem, properly shares her 

key that Alice may transfer to the Post Office separately by secret key with the trustees of the Post Office (e.g., receiving 

means of a different shared key K. This way, divulging k from said trustees a certification that they got legitimate 

(e.g., for the purpose of convincing Bob of the value of shares of this user key) in some initial phase, and then 

E^(m)) does not force the Post Office and Alice to agree on performs Step Al of the above ECM protocol. If needed, 

another conventional key k. Bob may turn to the Post Office and instructs the trustees to 

It should also be appreciated that the digital signatures of reconstruct Alice's user key. By doing so, the trustees cannot 

the ECM system need not be public key signatures. For monitor or cause the Post Office to monitor the message 

instance, there may be private key digital signatures or addressed by Alice to Bob, but can reconstruct the triplet (A, 

signatures verifiable with the help of other parties, or other B, E(m)). To insure that the Post Office trustees do not 

suitable forms of message authentication. Thus, as used collude with Bob in depriving Alice of her receipt, it can be 

herein, "digital signatures" and "digital signing" should be arranged that each trustee, when contributing its own piece 

broadly construed. Similarly, the notion of encryption with of a user secret key, also gives a proper acknowledgement to 

a key of some parly should be broadly construed to include that user. Thus, unless all n Irxistees do not behave properly, 

encrypting with a public key of that party or encrypting with Alice would receive at least one receipt, 

a secret key shared with that party or known to that party. A possible drawback of this fair-cryptography based 

There may also be concem that the Post Office will system is that Alice must interact with the trustees in order 
collude with one of the parties. For instance, the Post Office to give them shares of her user key. Thus, the trustees are not 
may collude with Bob who, rather than sending the receipt 45 ftilly invisible. This interaction may not even be confined to 
to Alice, goes directly to Post Office, and this enables Bob a single initial phase. This is because Alice may not be able 
to understand his message but without giving Alice any to reuse her key after Bob accesses the Post Office and 
receipt. This may occur in ordinary certified mail. Indeed, causes its reconstruction. To alleviate this problem, it might 
one who delivers the post may leave a letter with his be desirable to use physically secure devices and having the 
intended recipient without asking him or her to sign a 50 trustees reveal their own pieces to such a device, which 
receipt. Nonetheless, this potential problem may be dealt would then be able to announce (A,B,Es{m)) without proof, 
with effectively and efficiently. For instance, the Post Office A better approach uses the ECM protocol, but involves 
may be (or make use of) a physically secure device. Assum- splitting the secret key of the Post Office rather than the 
ing that the Post Office uses such a device in the preferred secret user keys. Thus, Alice would continue to encrypt (A, 
embodiment, then it will be hard for user Bob to have the 55 B, E^(m)) with the help of the Post Office public key, whose 
Post Office decrypt (A, B, EJm)) for him without sending corresponding secret key is shared among the n trustees but 
Alice her receipt. Indeed, the chip can be programmed to is not known to any single entity (nor has it been prepared 
perform both operations or none. Although use of physically by any single entity). Thus, the n trustees must cooperate, 
secure devices might increase the cost of a system, this need under Bob's proper request, in removing the Post Office's 
not be the case. Indeed, while they may be millions of users, encryption layer. However, they do so without reconstruct- 
there may be one or much fewer Post Offices. (Each user, of ing the Post Office secret key, not even internally to the Post 
course, may benefit also from being or relying upon physi- Office. To this end, a threshold cryptosystem may be used), 
cally secure devices.) ITiis solution is now illustrated using the well-known Diffie- 

While the inventive ECM system is very economical as it Hellman public-key cryptosystem. 
requires at most three communication steps, the goals can be 65 In the Diffie-Hellman system, there is a prime p and a 

accomplished also by more steps. In particular, although the generator g common to all users. A user X chooses his own 

trusted party, upon receiving Bob's communication, can secret key x at random between 1 and p-1, and sets his 
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public key to be g;^ mod p. Let y and mod p, respectively, knows the message precisely (but it is desired that he receive 

be the secret and public keys of user Y. Then X and Y it from Alice in an official and certified manner), then the 

essentially share the secret pair key mod p. Indeed, each parties may use a customization step so that, for example 

of X and Y can compute this pair-key by raising the other's SIG^(m,E5(m)) is the value produced by Alice and unpre- 
public key to his own secret key mod p. On the other hand, 5 dictable to Bob 

without knowledge of x or y no other user given the pubHc .^^^^^.^'^ ^ ^ ,^ j^^^.^^,^ ^^^^^ 

keys or mod p and a mod p and based on any known , . , . • l • . . r 

method, can compute The pair-key g-> Thus X and y can use tronic transactior^ that require the simultaneous exchange of 

this key to secure communications between each other (e.g., ynpredictable values. One such example, not meant to be 

by using it as the key of a symmetric cipher). ^^"^^^^"g' involves a contract closmg wherem a pair of 

r ^ T iu^ t«.ot^oo r.f iu. D^ot Mffl^^ users desire to sign a contract at a particular time and place. 

Let now 1,, . . . , r„ be the trustees 01 the Post Omce. ™ . ^, ... j n 1 . • . 

™ u u *i - J . u- ui* The mvention thus allows Alice and Bob to sign a contract 

Then, each T chooses a secret key XI and a matching public . . , • -ui *u- j ^ t j j c . 

key r mod p. Then the public key of the Post Office is set s'^Kaneously w.th an mvts.ble th.rd party, ndeed. the fl^t 

. u *i. J . f *u ui- 1 J ^ J /• value may be Alice s signature of the contract C and the 

to be the product of these public keys mod p, mod p (i.e., j 1 n !_> • . r • r 

g-og-i- •'•«'• mod p).nius. each trustee has a share of the ^™ t sY natureof'c"^*' ' ""^^^^ 

corresponding secret key, z. Indeed, the Post Ofi5ce*s secret ^ 

key would be z=xl+. . . +xn mod p-1. Assume now that '° particular, assume that Alice and Bob have already 

Alice wishes to encrypt (A, B, Es(m)) with the Post OfiBce's negotiated a contract C. Then, Alice and Bob agree (in a 

key. She selects a (preferably) temporary secret key a and its preliminary agreement) (a) that Alice is committed to C if 
corresponding public key g^ mod p. She then computes the -q ^^b gets the message consisting of Alice's signature to C, 

public pair-key g"^ mod p, encrypts (A, B, E^im)) conven- ^^at Bob is committed to C if Alice gets Bob's receipt 

tionally with the secret pair-key g*", and then sends Bob this ^^^^ message. This preliminary agreement can be "sealed" 

ciphertext together with the temporary public-key g^ mod p ^^^y ^^ys, for instance by signing, preferably 

(all in Step Al). If in Step Bl Bob sends AUce back a receipt, standardized, statements to this effect conventionally or 

namely, his signature of the received message, then Alice, in digitally. It does not matter who signs this preliminary 

Step A2, sends him the secret key a. This enables Bob to agreement first because Bob does not have Alice's message 

compute the pair-key g^ mod p (from a and the Post Office's ^^^^ have Bob's receipt. However, after both 

public key), and thus decrypt the conventional ciphertext to P^''^^^^ committed to the preliminary agreement, the 

obtain (A, B, E^(m)). Thus, if both users behave properly, inventive ECM system allows the message and the receipt to 
the Post Office is not involved in the transaction. Assume 3. ^e exchanged simultaneously, and thus C is signed simul- 

now that Bob properly asks the Post Office to decrypt Alice's taneously. Those skilled in the art also may realize it may be 

ciphertext. To do this, the trustees cooperate (preferably, ^^^^ convenient to first one-way hash C prior to signing it. 

with proper notice to Alice and to each other) in computing This method may be much more practical than accessing 

g'" mod p. To this end, each trustee T,. raises Alice's public a commonly trusted lawyer particularly, when the contract in 
key g" mod p to its own secret key. That is, T^- computes g""' 35 question may be very elementary or arises in an "automatic 

mod p. Then these shares of the pair-key are multiplied context". Generalizing, one may view a contract C as any 

together mod p to obtain the desired private pair-key. In fact, arbitrary signal or string of symbols to which the parties 

goxi . . . ^axn p=g^^-^- • • mod p=g*'f'^^'^- ■ • "^"^^ mod wish to commit in a simultaneous way. The inventive 

psg""^ mod p. This key may be given to Bob, who can thus solution is very attractive because it can be implemented in 
obtain Egim). In this method, it may be useful to have a Post 43 software in many contexts, and because the trustee is invis- 

Office representative handle the communications with Bob, ible and need not be called into use if the signatories behave 

while the individual trustees handle directly their sending properly. This minimizes cost and time, among other 

Alice receipts. resources. In this application, the trustee, rather than a post 

This method can be adjusted so that sufficiently few office, may be a "financial service center" that facilitates the 
(alternatively, certain groups of) trustees cannot remove the 45 transactions of its own customers. 

Post Office's encryption layer, while sufficiently many Yet another application of the invention is to make 

(alternatively, certain other groups of) trustees can. For simultaneous the result of applying a given function to one 

instance, there can be kn trustees, and each of the n trustees or more secret values, some belonging to Alice and some 

acting as above can give his own secret key to each of a belonging to Bob. For example, the inventive method allows 
group of k-1 other trustees. Thus, each distinct group of k 50 implementation of "blind" negotiations. In this embodiment, 

trustees has knowledge of a secret key as above. Further, the assume a seller Alice and a buyer Bob desire to determine 

above-described modifications to the single invisible-trustee whether Alice's (secret) minimum selling price is lower than 

ECM protocol can be applied to embodiments involving Bob's (secret) maximum selling price (in a way that both 

multiple trustees. parties will learn the result simultaneously). If the answer is 

In the ECM system involving fair cryptography, even a 55 no, then the parties may either try again or terminate the 
user might be or rely upon a multiplicity of entities. Indeed, negotiation. Alternatively, if the answer is yes, then prefer- 
in the invention, "user" or "parly" or "trusted party" thus ably the parties also will be committed to the transaction at 
should be construed broadly to include this possibility. some value. (For example, the average of the two secret 

It should be appreciated that the inventive ECM systems values), 
enable Alice and Bob to exchange simultaneously two 60 Another useful application of the invention is during a bid 

special values, the first, produced by Alice, which is (at least process, such as in an auction. For instance, assume that 

reasonably) unpredictable to Bob, and the second, produced multiple bidders wish that their secret bids be revealed 

by Bob, which is unpredictable to Alice. Indeed, the value simultaneously. One bidder may also wish that his or her bid 

produced by Bob and unpredictable to Alice may be Bob's be independent of the other bids, 
signature of step Bl. If the message is not known precisely 65 What is claimed is: 

by Bob, then the message itself may be the value produced 1. A method of communicating between a first and second 

by Alice and unpredictable to Bob. Alternatively, if Bob party, comprising the steps of: 
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initiating.an-exchange-of-messages-between4herfirst and 12. The electronic communication method of claim 9, 

C^cond^parUesIwithout'inle^^ third wherein the first message includes information indicating 

^partyrand the first party is involved in the message, 
in res ponse t o .one^ofahe-first-and-second_parties,Dot l^. The electronic communication method of claim 9, 

rcceiving-arleast miel)f th"eme^^^^ 5 wherein the first message includes information indicating 

of theJirst-and-secondlpafti^h'^iHMhe-tr usted-thiFP ^^^^ Pf ^ evolved in the message, 

p^arty takTSSJu^rovide-appropPi^ electronic communication method of claim 9, 

fiTst::OT:iiSSi5^partiEi^ ' ^^^''^'^ ^^"^ message has a portion unpredictable to 

2. An electronic communication method comprising: ^^^^ ^^^LF^^^-(' . . . 

A C c * * r * 4 u • ju in 15. The electronic communication method of claim 9, 

sending from a first party a first message to be received by . . , , • , , , . 

J * . • * * • I * . J *u - J wherein the second message includes a valid signature of the 

a second party without intervention by a trusted third , ^ . - • c , n 

, X / r »u * « f ;u c 4 second parly or information representative of the first mes* 
party, at least some of the contents of the first message ^ *^ 

sape 

being unintelligible to the second party; -r^ t - • • ..ri ^ 

. . , . ° , r , lo- The electronic communication method of claim 9, 

receiymg_by_the_first_party a_second_message.from-^^^ ^^^^^-^ l^^t ^ g^^j ^ ^ unintelligible 

second-partrver^ ^^^^^ ^^.^^ p^^^^ 

theJmLmessage;-andrO electronic communication method of claim 9, 

sendmg from the first party a third message enabling the therein the second message is based on information not 

second party to understand the contents of the first ^nown by the trusted third party. 

message unintelligible to the second party; ^ ^-^e electronic communication method of claim 9, 

wherein the at least some-og -the-contents-arc -able ^ be wherein at least a part of the second message is unintelligible 

ren^eredxnteingiblejonMlseco^ to the trusted party. 

dp^5L^e^figt-part y,-and^ 19 The electronic communication method of claim 9, 

the-at'least some of the contents are able tojbe-r^ndered further comprising receiving, by the first party after sending 

inte^igible-tO-the,sccond£art>ahgugh,assi^^ the first message and before receiving the second message, 

tpis^ithird^arty — — a third message. 

3. ^I'he electronic communication method of claim 2, 20. The electronic communication method of claim 19, 
further comprising generating, by the first party, the first wherein: 

message using information not known by the second party. the third message verifies receipt of the first message by 

4. The electronic communjc ation method of claim 2 , the second party; and 
where,in:the=firet-message-iiEl5de£a the first party sends'no other messages to the second party 
cbyjherfiist:paTtyrof:atzleast:st>me-Gf-the-contents-UflinteUi- ^^^^^^ receiving the second message. 

gible to the second party. 21. The electronic communication method of claim 19, 

5. The electronic communication method of claim 2, wherein the third message does not verify receipt of the first 
wherein the first message includes mformation indicating 3^ message by the second parly 

the first party is involved in the message, 22. The electronic communication method of claim 21, 

6. The electronic communication method of claim 2, wherein the third message does not verify receipt of the first 
wherem the first message includes information indicating message by the second party because it does not include a 
the second party is involved m the message. ^^lid signature by the second party of information rcpre- 

7. The electronic communication method of claim 2, seniative of the first message. 

wherein the second message has a portion unpredictable to 23. The electronic communication method of claim 22, 

^ o ^^^^"^7" ■ . J r . ^ further comprising determining, by the first party, that a 

8. The electromc communication method of claim 2, signature in the third message is not a valid signature of the 
wherein the second message includes a valid signature of the second party 

second party of information representative of the first mes- 24. The electronic communication method of claim 22, 

^^S^* further comprising determining, by the first party, that a 

9. Anelectronic communication method comprising: signature in the third message is not a signature of a given 
gselTding-fro m a-firsta party a first message to be received by portion of the first message. 

a second party without intervention by a trusted third 25. The electronic communication method of claim 24, 

party, at least some of the contentsioflbe^stjnessage further comprising sending, by the first party after sending 

beingjinintelligible to the second party; and the first message and before receiving the second message, 

Xecciving-byjlhe first party ^a se co nd mes sage from the a third message to be received by the second party, where the 
trusted third party, the second^essage^ifyin g-that^ third message does not satisfy a predetermined criterion. 
the::secQnd,party,recciyed:the~first:rne^gg; 26. The electronic communication method of claim 25, 

wherein the at least some of the contents are able to be 55 wherein the predetermined criterion is one of that the third 

rendered intelligible to the second party through assis- message enables intelligible disclosure of the contents of the 

tance of the first party, and first message unpredictable to the second party. 

the at least some of the contents are able to be rendered 27. The electronic communication method of claim 25, 

intelligible to the second party through assistance of the wherein the predetermined criterion is that the third message 
trusted third party. 60 does not include a valid signature of information represen- 

10. The electronic communication method of claim 9, tative of the contents of the first message unpredictable to 
further comprising generating, by the first party, the first the second party. 

message using information not known by the second party. 28. An electronic communication method comprising: 

11. The electronic communication method of claim 9, receiving by a first party a first message from a second 
wherein the first message includes a valid digital signature 65 party without intervention of a trusted third party, at 
by the first party of at least some of the contents unintelli- least some of the contents of the first message being 
gible to the second party. unintelligible to the first party; 
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sending by the first party a second message verifying that 40. The electronic communication method of claim 38, 

the first party received the first message; and wherein the fourth message does not verify receipt of the 

receiving by the first party a third message from the ^^st message by the first party, 

second party enabling the first party to understand the '^1 electronic communication method of claim 38, 
contents of the first message unintelligible to the first 5 wherem the fourth message docs not verify receipt of the 

first message by the first party because it does not include a 

^ ^* valid signature by the second party of information repre- 

wherein the at least some of the contents are able to be sentative of the first message. 

rendered intelligible to the first party through assistance 42. The electronic communication method of claim 38, 

of the second parly, and further comprising receiving, by the first party after sending 

the at least some of the contents are able to be rendered the fourth message and before receiving the trusted third 

intelligible to the furst party through assistance of the message, a fifth message from the second party, where the 

trusted third party. ^^Ih message does not satisfy a predetermined criterion. 

29. The electronic communication method of claim 28, ^3. The electronic communication method of claim 42, 
wherein the first message includes a valid digital signature wherein the predetermined criterion is that the fifth message 
by the second party of at least some of the contents unin- ^""^^ j"^^"^^ ^"^^^^^ of the first message unintelli- 
telligible to the first party. ^'^}^, ^^^^ second party. 

30. The electronic communication method of claim 28, ^^^^^^^^ commumcation method of claim 42, 
, ■ ,u c . -ij • c *• J-*- wherein the predetermined criterion IS that the fifth message 

wherem the first message includes mformation mdicatmg ^^^^ ^^^^^^ ^ ^^^.^ ^. ^^^^^^ ^^^^^^^ ^f^^ 

the second party IS involved in the message ^ ^ . 20 message unintelligible to The second party. 

31. The electronic communication method of claim 28, 45 ^ electronic communication method comprising: 
wherein the first message includes information mdicatmg ^ ^ ^^^^^^ ^^^^ ^ ^^^^ ^ ^^^^ ^ 
the first party is mvolved m the message. ^^^^^ p^^y verifying that the second party received a 

32. The electronic communication method of claim 28, s^^ond message from a third party without intervention 
wherein the second message has a portion unpredictable to of the trusted first party, the second message including 
the second party. a portion unintelligible to the second party; 

33. 'Ilie electronic communication method of claim 28, sending by the trusted first party a trusted third message 
wherein the second message includes a valid signature of the to the third party, the trusted third message verifying 
first party of information representative of the first message. that the second parly received the second message from 

34. An electronic communication method comprising: the third party; and 

receiving by a first party a first message from a second sending by the trusted first party a trusted fourth message 

party without intervention of a trusted third party, at to the second party, the trusted fourth message enabling 

least some of the contents of the first message being intelligible disclosure to the second party of the portion 

unintelligible to the first party; of the second message unintelligible to the second 

sending by the first party a second message to the trusted 35 party; 

third party, the second message verifying that the first wherein the portion is able to be rendered inteUigible to 

party received the first message; and the second party through assistance of the third party. 

receiving by the first party a third message from the electronic communication method of claim 45, 

trusted third party, the third message enabling the first wherein at least a portion of the first message is unintelU- 

party to understand the contents of the first message ^^^^^ ^^e trusted first party. 

unintelligible to the first party; ^"^^ electronic communication method of claim 45, 

. . . , c ^ , Li * i_ wherein the first message is based on information not known 

wherein the at least some of the contents are able to be trusted first art 

rendered inteUigible to the first party through assistance °^q^J^!^^i ^ *u ^ r 1 • ac 

of the second art and & 45. The electronic communication method of claim 45, 
^ 45 wherein the first message includes a digital signature of the 

the at least some of the contents are able to be rendered third party 

intelligible to the first party through assistance of the 49 The electronic communication method of claim 48, 

trusted third party. wherein the digital signature of the third party signs at least 

35. The electronic commumcation method of claim 34, ^ potion of a message from the second party to the third 
wherein the first message is based on information not known party 

by the first party. 50 The electronic communication method of claim 45, 

36. The electronic commumcation method of claim 34, ^^^^^^^ ^t least a portion of the trusted third message is 
wherem at least a part of the second message is unpredict- unpredictable to the trusted first party. 

able to the trusted third party. 5^ electronic communication method of claim 45, 

37. The electronic communication method of claim 34, ^^erein the trusted third message is based on information 
wherein the second message is based on infonnation not ^nown by the trusted first party. 

known by the trusted third party. 52, The electronic communication method of claim 45, 

38. The electronic commumcation method of claim 34, wherein at least a portion of the trusted fourth message is 
further comprising sending, by the first party after receiving unintelligible to the trusted first party. 

the first message and before receiving the trusted third 53 electronic communication method of claim 45, 

message, a fourth message to the second party. wherein at least a portion of the trusted fourth message is 

39. The electronic communication method of claim 38, ^^^^^ information not known to the tnisted first party, 
wherein: 54 ^ method of processing an electronic message com- 

the fourth message verifies receipt of the first message by prising: 

the first party; and ^5 processing an original message with a first key to produce 

the first party receives no other messages from the second a first processed message readable only by a parly 

party before receiving the trusted third message. having a second key; 
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customizing the first processed message to indicate the 
party having the second key as a recipient thereof, 
thereby producing a customized first processed mes- 
sage; and 

encrypting the customized first processed message with a 
third key to produce a second processed message 
readable only by a party having a fourth key, 

55. The method of claim 54, wherein the first and second 
keys are different from one another. 

56. The method of claim 54, wherein the third and fourth 
keys are different from one another, 

57. The method of claim 54, wherein customizing com- 
prises customizing the first processed message to indicate a 
party producing the first processed message as a sender 
thereof. 

58. The method of claim 54, wherein the party having the 
fourth key is a trusted party. 

59. The method of claim 54, further comprising process- 
ing the second encrypted message with a fifth key to produce 
a third processed message. 

60. The method of claim 59, wherein the party having the 
fifth key is the party having the second key. 

61. The method of claim 60, wherein the second key and 
the fifth key are identical, 

62. ITie method of claim 59, where the third processed 
message uniquely identifies a party which produces it. 

63. The method of claim 62, wherein the party which 
generates the third processed message is the party having the 
second key. 

64. The method of claim 59, further comprising process- 
ing the third processed message with the sixth key to 
produce the second processed message. 

65. The method of claim 64, wherein the third processed 
message is processed by a trusted party. 

66. The method of claim 64, further comprising process- 
ing the second processed message, produced by processing 



10 



the third processed message, with the fourth key to produce 
the first processed message. 

67. The method of claim 66, wherein the second pro- 
cessed message, produced by processing the third processed 

5 message, is processed by a trusted party. 

68. The method of claim 59, wherein message processed 
using the first key are readable using the fifth key. 

69. A method of processing an electronic message com- 
prising: 

processing a first processed message, readable only by a 
party having a first key, with a second key to produce 
a second processed message uniquely identifying the 
party processing the first processed message; 
IS wherein the first processed message is a representation of 
an original message processed with a third key to 
obtain a third message, readable only to a party having 
a fourth key, which is further processed with a fifth key 
to obtain the first processed message. 
20 70. The method of claim 69, wherein the party processing 
the first processed message is the party having the fourth 
key. 

71. The method of claim 70, wherein messages processed 
using the second key are readable by processing them with 

25 the third key. 

72. The method of claim 69, wherein the party having the 
first key is a trusted party. 

73. The method of claim 69, further comprising process- 
ing the second processed message using a sixth key to obtain 

30 the first processed message. 

74. The method of claim 73, wherein the second pro- 
cessed message is processed by a trusted party. 

75. The method of claim 73, wherein messages processed 
using the second key are readable using the sixth key. 

35 
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SIMULTANEOUS ELECTRONIC 
TRANSACTIONS WITH VISIBLE TRUSTED 
PARTIES 

RELATED APPUCATION 

This application is a continuation of Sen No. 08/700,270, 
filed Aug. 20, 1996, now U.S. Pat. No. 5,629,982, which is 
a a continuation of application Ser. No. 08/511,518 filed on 
Aug. 4, 1995 now U.S. Pat. No. 5,553,145, which is a 
continuation-in-part of prior application Ser. No. 08/408, 
551, filed Mar. 21, 1995 now abandoned. 

TECHNICAL FIELD 

The present invention relates generally to ^ejejctrflnic^c om- 
merce and Uiaasaetions*^d more particularly to techniques 
for enabling users to effect certified mail, contract signing 
and other electronic notarization functions. 

BACKGROUND OF THE INVENTION 

The value of many transactions depends crucially on their 
simultaneity. Indeed, simultaneity may be so important to 
certain financial transactions that entities often are willing to 
incur great inconvenience and expense to achieve it. For 
example, consider the situation where two parties have 
negotiated an important contract that they now intend to 
"close." Often, the parties find it necessary to sign the 
document simultaneously, and thus they meet in the same 
place to watch each other's actions. Another example is the 
process of certified mail, where ideally the sender of a 
message desires that the recipient get the message simulta- 
neously with the sender's obtaining a "receipt". A common 
certified mail procedure requires a person who delivers the 
mail to personally reach the recipient and obtain a signed 
acknowledgment when the message is delivered. This 
acknowledgment is then shipped to the sender. Again, this 
practice is costly and time consuming. Moreover, such 
acknowledgments do not indicate the content of the mes- 
sage. 

In recent years, the cost, efficiency and convenience of 
many transactions have been improved tremendously by the 
availability of electronic networks, such as computer, 
telephone, fax, broadcasting and others. Yet more recently, 
digital signatures and public-key encryption have added 
much needed security to these electronic networks, making 
such communication channels particularly suitable for 
financial transactions. Nevertheless, while electronic com- 
munications provide speed, they do not address simultaneity. 

The absence of simultaneity from electronic transactions 
severally limits electronic commerce. In particular, hereto- 
fore there has been no effective way of building so-called 
simultaneous electronic transactions ("SET's"). As used 
herein, a SET is an electronic transaction that is simulta- 
neous at least in a "logically equivalent" way, namely it is 
guaranteed that certain actions will take place if and only if 
certain other actions take place, One desirable SET would be 
certified mail, however, the prior art has not addressed this 
problem effectively. This can be seen by the following 
consideration of a hypothetical example, called ideal certi- 
fied mail or "ICM". In an ICM transaction, there is a sender, 
Alice, who wishes to deliver a given message to an intended 
recipient. Bob. This delivery should satisfy three main 
properties. First, Bob cannot refuse to receive the message. 
Second Alice gets a receipt for the message if and only if 
Bob gets the message, lliird, Alice's receipt should not be 
"generic," but closely related to the message itself. Simul- 
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taneity is important in this transaction. For instance, Alice's 
message could be an electronic payment to Bob, and it is 
desired that she obtains a simultaneous receipt if possible. 

Alice could try to get a receipt from Bob of a message m 
5 in the following way. Clearly, sending m to Bob in the clear 
as her first communication does not work. Should this 
message be her digital signature of an electronic payment, a 
malicious Bob may lose any interest in continuing the 
conversation so as to deprive Alice of her receipt. On the 
10 other hand, asking Bob to send first a "blind" receipt may not 
be acceptable to him. 

Another alternative is that Alice first sends Bob an 
encryption of m. Second, Bob sends Alice his digital sig- 
nature of this ciphertext as an "intermediate" receipt. Third, 
Alice sends him the decryption key. Fourth, Bob sends Alice 
a receipt for this key. Unfortunately, even this transaction is 
not secure, because Bob, after learning the message when 
receiving Alice's key, may refuse to send her any receipt. 
(On the other hand, one cannot consider Bob's signature of 
the encrypted message as a valid receipt, because Alice may 
never send him the decryption key.) 

These problems do not disappear by simply adding a few 
more rounds of communication, typically consisting of 
"acknowledgments". Usually, such additional rounds make 
it more difficult to see where the lack of simultaneity lies, but 
they do not solve the problems. 

Various cryptographic approaches exist in the literature 
that attempt to solve similar problems, but they are not 
satisfactory in many respects. Some of these methods appli- 
cable to multi-party scenarios propose use of verifiable 
secret sharing (see, for example, Chor ct al), or multi-party 
protocols (as envisioned by Goldreich et al) for making 
simultaneous some specific transactions between parties. 
Unfortunately, these methods require a plurality of parties, 
the majority of which are honest. Thus, they do not envision 
simultaneous transactions involving only two parties. 
Indeed, if the majority of two parties are honest then both 
parties are honest, and thus simultaneity would not be a 
problem. Moreover, even in a multi -party situation, the 
complexity of these prior art methods and their amount and 
type of communication (typically, they use several rounds of 
broadcasting), make them generally impractical. 

Sophisticated cryptographic transactions between just two 
45 parties have been developed but these also are not simulta- 
neous. Indeed, if just two people send each other strings 
back and forth, and each one of them expects to compute his 
own result from this conversation, the first to obtain the 
desired result may stop all communications, thereby depriv- 
50 ing the other of his or her result. Nonetheless, attempts at 
providing simultaneity for two-party transactions have been 
made, but by using assumptions or methods that are unsat- 
isfactory in various ways. 

For example, Blum describes transactions that include 
55 contract signing and certified mail and that relies on the two 
parties having roughly equal computing power or knowl- 
edge of algorithms. These assumptions, however, do not 
always hold and are hard to check or enforce anyway. In 
addition, others have discovered ways to attack this rather 
60 complex method. A similar approach to simultaneity has 
also been proposed by Even Goldreich and Ijempel. In 
another Blum method for achieving simultaneous certified 
mail, Alice does not know whether she got a valid receipt. 
She must go to court to determine this, and this is undcsir- 
65 able as well. 

A method of Luby el al allows two parties to exchange the 
decryption of two given ciphertexts in a special way, namely, 
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for both parties the probability that one has to guess cor- 
rectly the cleartext of the other is slowly increased towards 
100%. This method, however, does not enable the parlies to 
achieve guaranteed simultaneity if one party learns the 
cleartext of the other's ciphertext with absolute certainty 5 
(e.g., by obtaining the decryption key); then he can deny the 
other a similar success. 

For this reasons several researchers have tried to make 
simultaneous two-party transactions via the help of one or 
more external entities, often referred to as "centers", "serv- lO 
ers" or "trustees", a notion that appears in a variety of 
cryptographic contexts (see, for instance, Needham and 
Schroder and Shamir). A method for simultaneous contract 
signing and other transactions involving one trustee (called 
a "judge") has been proposed by Ben-Or et al. Their method 
relies on an external entity only if one parly acts dishonestly, 
but it does not provide guaranteed simultaneity. In that 
technique, an honest party is not guaranteed to have a signed 
contract, even with the help of the external entity. Ben-Or et 
al only guarantee that the probability that one party gets a 
signed contract while the other does not is small. The smaller 
this probability, the more the parlies must exchange mes- 
sages back and forth. In still another method, Rabin envi- 
sions transactions with the help of external party that is 
active at all times (even when no transaction is going on), 
but also this method does not provide guaranteed simulta- 
neity. 

The prior art also suggests abstractly that if one could 
construct a true simultaneous transaction (e.g., extended 
certified mail), then the solution thereto might also be useful 
for constructing other types of electronic transactions (e.g., 
contract signing). As noted above, however, the art lacks an 
adequate teaching of how to construct an adequate simul- 
taneous transaction. 

ITiere has thus been a long-felt need in the art to overcome 
these and other problems associated with electronic trans- 
actions. 

BRIEF SUMMARY OF TIIE INVENTION 

It is an object of the invention to provide true simulta- 
neous electronic transactions. 

It is a further object of the invention to provide electronic 
transactions having guaranteed simultaneity in a two-party 
scenario with the assistance of a visible trusted party. 

It is another more specific object of the invention to 
provide ideal certified mail wherein the identity of the 
sender is temporarily withheld from the recipient during the 
transaction. 

It is still another object of the invention to provide a 50 
simultaneous electronic transaction wherein the recipient 
can prove the content of a message and a receipt provided to 
the sender proves the content of the message. 

These and other objects are provided in an electronic 
communications method between a first and a second party, 55 
with assistance from at least a trusted party, enabling an 
electronic transaction in which the first party has a message 
for the second party. A first method, called the sending 
receipt approach, begins by having the first party transmit to 
the trusted parly a custom version of the message intelligible 60 
to the second party but not by the trusted party. In response, 
the method continues having the trusted party verify that the 
first party transmitted the custom version of the message and 
that the second party is the intended recipient thereof. The 
trusted party then transmits to the second party information 65 
from which the second party can retrieve the message. Then, 
the trusted party transmits to the first party a sending receipt 



indicating that the message has been transmitted to the 
second party. At least one of the transmissions is carried out 
electronically. 

According to an alternative embodiment, called the return 
receipt approach, the method begins having the first party 
transmit to the trusted party a custom version of the message 
intelligible to the second party but not by the trusted p^rty^ 
In respo nse, <th c-mcthod~continues-by^iraving thc~TrusteO 
party'~vcnfy_jh at the fi rst p^ y transmitted the custom 
version-of"theTnessage~and~that~the'second"paTty is th^ 
imeTrdrdrreXipient:thereofr3T^ 

information which determines 



.thc-sccond_ party 



first 



messagebutretains thelmessageand the identity of the fijst^ 
partphidden from the second party.^*rtest"is~then~done^to 
» determ ine- whether" within~a~given^ time the second party 
transmits to the trusted party a return receipt indicating that 
the second party received the transmission of the first 
information from the trusted party. If the second party 
transmits the return receipt to the tmsted party, the method 
' hasjhe-trusted party (i):tr;ansmiUo:the:sec»n^ 
^^ififormatipn.fro 

second-informationr-^'^~-retfieveI 
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.message, 

transmit to^tfaerfirslnJartyiairecci pt-thatthe'second jartv^^ 
received the message. Again, at least one of the transmis- 
sions is carried out electronically. 

Many other electronic communications methods are 
described wherein the first party, the second party and the 
trusted party undertake an exchange of transmissions, at 
least one of which occurs electronically and in an encrypted 
manner, such that if all transmissions reach their destinations 
the second party only receives the message if the first party 
receives at least one receipt. At least one receipt received by 
the first party enables the first party to prove the content of 
the message received by the second party. 

BRIEF DESCRIPTION OF THE DRAWINGS 

For a more complete understanding of the present inven- 
tion and the advantages thereof, reference should be made to 
the following Detailed Description in conjunction with the 
accompanying drawings in which: 

FIG. 1 illustrates a preferred sending receipt method of 
the invention; and 

FIG. 2 illustrates a preferred return receipt method of the 
invention. 

DETAILED DESCRIPTION 

In each of the schemes described below, there is a user 
Alice and a user Bob. The trusted party may be a financial 
center that facilitates SETs among its customers, including 
Alice and Bob. For convenience, the following description 
shows how to make extended certified mail "simultaneous", 
although the invention is not so limited. In the context of an 
ICM system, the third party is called the Post OfiSce. The 
inventive scheme is also preferable to ordinary certified mail 
because the message receipt also guarantees the content of 
the message. Also, the electronic transaction is faster, more 
informative and more convenient than traditional certified 
mail, and its cost should be substantially lower. 

In the preferred embodiment, an extended certified mail 
system is provided using a single "trusted" party. The system 
is implemented in a computer network, although it should be 
realized that telephone, fax, broadcast or other communica- 
tion networks may be used. Thus, without limitation, it is 
assumed that each user in the system has a computer capable 
of sending and receiving messages to and from other com- 
puters via proper communication channels. 
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Each user in the system has a unique identifier. Alice^s 
identifier is denoted by A, and Bob's identifier is B. The 
identifier of the Post OflSce is denoted by PO. Users and the 
Post OflBcc can digitally sign messages. Thus, each has a 
secret signing key and a matching public verification key. If 5 
m is a message (string), then SIG^(m) indicates Alice's 
signature of m. (It is assumed, for convenience, that m is 
always retrievable from its signature. This is the case for 
most signature schemes, and it is otherwise possible to 
consider a signed message as the pair consisting of the lO 
message and its signature.) 

Users and the Post OflSce can encrypt messages by means 
of a public -key encryption algorithm (e.g., RSA). Thus, each 
has a public encryption key and a corresponding secret 
decryption key. E^(m), E^(m), and Ej>^(m) denote, 15 
respectively, the encryption of a message m with the public 
key of Alice, Bob, and the Post OfiBce. For simplicity, it is 
assumed that these schemes are secure in the sense that each 
of EA', EB* and E^^ appear to behave as a random function. 
The system can be suitably modified if these functions are 
much less secure. 

Again, for simplicity these encryption algorithms are 
deterministic and uniquely decodable. Thus, given a value y 
and a message m, all can verify whether y is the encryption 
of m with, for example, the Post Office's key, by checking 
whether Ep^(rn) equals y. (If the encryption scheme is 
probabilistic, then one may convince another that a string y 
is an encryption of a message m by providing m together 
with the random bits that were used to encrypt m.) (It may 
also be possible to use encryption algorithms that are not 
uniquely decodable, for instance, if it is hard to decrypt a 
given ciphertext in two difl[erent ways.) For simplicity, if 
public key encryption algorithms are used, messages are 
encrypted directly with a public-key algorithm, however, 
one could first encrypt a message conventionally with some 
key k, and then encrypt k with a public-key algorithm. 
(Thus, to decrypt ra, one need only just decrypt k). Indeed, 
private key encryption algorithms could be used throughout. 

According to the invention, it is desired to devise practical 
[CM methods, involving more visible trustees, that (1) 
produce receipts closely tied to the content of the mail, (2) 
hide (at least temporarily) the identity of senders firom the 
recipients, and (3) can be implemented in a pure electronic 
manner (at least, as long as senders and recipients behave 
properly). 

THE SENDING-RECEIPT METHOD 

To describe the various methods of the present invention, 
assume there are senders, receivers and post offices. It 50 
should be clear, however, that each of these may be any 
entity, such as a person, a person's representative, a physical 
device (in particular, a tamper-proof device) or a collection 
of people and/or physical devices. For example, the Post 
Office could be a tamper-proof device located in a device or 55 
facility belonging to Alice and/or Bob. 

Also, in the preferred embodiments, Alice, Bob and the 
Post Office all have public encryption keys and matching 
secret decryption keys (e.g. hke in the RSA algorithm), that 
their cryptosystem behave Hke random functions, and that 60 
they can digitally sign messages (preferably by an algorithm 
different than their encryption one). An encryption of a 
string s with the public key of Alice, Bob, and the Post Office 
will be denoted, respectively, as E^(s), E^(s), Ej>o(s). The 
digital signature of a string s by Alice, Bob, and the Post 65 
Office will, respectively, be denoted by SIG^(s) SIGfl(s), and 
SlGp^(s). (it is understood that messages can be one-way 
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hashed prior to being signed, together with other valuable 
information, such as recipient, time, transaction type, sender 
and recipient, etc.) Identifiers for Alice, Bob, and the Post 
Office will, respectively, be denoted by A, B, and PO. 

In the present invention, a customization step is used by 
Alice to identify (usually to the Post Office) herself as the 
sender and Bob the (ultimate) recipient of some siring s 
(usually a message m encrypted with Bob's public encryp- 
tion key). This step prevents cheating. In particular, it 
prevents an enemy from sending to Bob the same message 
Alice does and in a certified manner. Any customization step 
is in the scope of the present invention. A simple such step 
consists of having Alice send the Post Office a value 
z°Epo{A, B, Ej3(m)). Indeed, should the Post Office receive 
from some user X other than Alice the value z, upon 
decrypting it with its secret decryption key, it will compute 
(A, B, E^(m) and thus realize that there is a problem with the 
identity of the sender. 

The above customization works well if the encryption 
function behaves as a random function. Alternative and 
more sophisticated customizations, all within the scope of 
the invention, are also possible. For instance, Alice may send 
the Post Office z=E^o(SIG^(ICM, B, Ej^(m))), where the 
identifier ICM signifies that z is part of an electronic certified 
mail transaction. Such identifiers may be dismissed, particu- 
larly if standard formats are adopted for ICM transactions. 
As another example, Alice may achieve customization by 
using identifiers and her digital signature both outside and 
inside the Post Office's encryption layer: z«SIG^(A, B, 
Epc>(SIG^(A, B, Ea(m)))). In some contexts (e.g., but with- 
out limitation, when the communications channel is believed 
to be secure), it may suffice to use a customization where the 
identity of the sender and the message are sent separately, 
whether or not signed together (e.g., (B, E^(m)) or SIG^(B, 
E«(m))). 

The basic electronic certified mail system with a visible 
party is now described. At least one transmission in the 
method below (and preferably all) are electronic, where by 
"electronic" we mean any non-physical delivery, including, 
without Umitation, transmissions via telephones, computer 
networks, radio, broadcasting, air waves, and the like. 

THE BASIC METHOD 

Al Sender Step): Let m be the message that Alice desires 
to send Bob by certified mail. ITien Ahce sends to the 
Post Office a customized version of m that is intelligible 
by Bob, but not by the Post Office, 
(e.g., she sends the value z-E^(A, B, E^(m)). 
Preferably, Alice's communication is digitally signed 
and indicates, in a standard manner, that it should be 
delivered certified to Bob. (e.g., using an alternative 
customization step, just for illustration purposes, she 
sends z«E^o(SIG^(ICM, B, E^(m))), or E^o(SIG^ 
(B, Eff(m))).) It is also preferable that Alice specifics 
additional valuable information, such as time infor- 
mation and information easily alerting the Post 
Office that her transmission is part of an ICM trans- 
action. 

POl (Post Office Step): After receiving Alice's 
transmission, the Post Office preferably uses the cus- 
tomization step to verify that Alice is the sender and 
Bob the intended recipient of this piece of electronic 
certified mail. If this is the case, then it sends to Bob 
information enabling him to retrieve Alice's message, 
preferably using digital signatures, and indicating to 
him but hiding from others that it is a piece of ICM 
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from Alice to him, (e.g., it sends y«E^SIGpo(ICM, A, ^b{^)) does not solve the problem. Indeed, an enemy X who 

B, E^(m))), or ICM, y, so that Bob it is more easily captures SlG^E5(m)), easily learns the value Ej(m) 

alerted that he is dealing with an ICM transaction). (because signatures generally guarantee the message, but do 

If Alice has made use of digital signatures (e.g., if she not hide it), and can then easily sign it himself, that, send 

has signed Es(m) or a value comprising it in Step AI, 5 (SIG;4£5(m)) as part of his own ICM transaction, 

then it is preferable that these signatures are also In the present invention, encryption of the message m 

forwarded to Bob, (e.g., if Alice sent the Post OflBce with a key associated to a party X, E;^^m), should be broadly 

the value SIG^(EB(m)) as part of her Step AI, then construed to include any information that enables X (and 

the Post OfiBce may send E^(SIGpo(ICM, A, B, only X) to retrieve the message m. For instance, E^m) may 

SIG^(E^(m)))) to Bob in this step.) lo consist of the encryption with a key associated with X of 

In addition, the Post OfiBce also sends Alice her receipt. another key with which the message m has already been 

Preferably this involves a digital signature that it has encrypted. (This other encryption of m may already be in 

sent Alice a message to Bob in a way intelligible to possession of X, or sent .separately to X, or publicly-known, 

him. Such a receipt preferably also indicates other or otherwise knowable by X). 

valuable information, such as the time, T, when this is The electronic sending-receipt method is more than 

was done, (e.g., it sends Alice E^(SIGj3q(I CM, A, B, equivalent to traditional certified mail (without return 

T Eg(m))).) receipt). Indeed, if digital signatures are properly used as 

The Post OfiBce of the Sending-Receipt Method is visible exemplified above, not only docs Bob learn (and can prove) 

because it takes part to the transaction whether or not Alice Alice's identity and get Alice's message, he can also prove 

and Bob behave honestly. It should be understood that each 20 to third parties what this message is. For instance, if the Post 

party to the transaction (whether the Sending Receipt OfiBce (in Step POl), sends him the value v«=(SIGpq(E^A, 

method or the Return Receipt method or other methods of B, E5(m))), if Bob hands out v and m to a third party, the 

the invention) may participate in the transaction via a latter can compute u«=E^m) by means of Bob's public 

representative. In such case, for instance, Alice may be encryption key, and then (again due to Bob's public encryp- 

identifled with a representative. Alternatively, it should be 25 tion key) the value s=E^(A, B, u), and, finally he can verify 

understood that a party may only be partially-identified with whether v is the Post OfQce's digital signature of s. If the 

his own representative. For instance, the message may be Post OfiBce is trusted with respect to deliver just what it is 

sent to Bob's representative but be intelligible only to Bob supposed to, then this is sufificient proof that Bob got m from 

himself. Alice via ICM. Indeed, Alice*s message can be defined to be 

The Post OfiBce is not trusted with the knowledge of 30 whatever string x can, when encrypted with Bob's key, 

Alice's (clcartext) message to Bob; indeed, it cannot under- yields the value E^(m). If such x is nonsensical, then Alice 

stand m. It is trusted, instead, to perform a proper deUvery, sent Bob a nonsensical message. This convention prevents 

which makes the Sending-Receipt Method a (logically) Bob from claiming that he did not really get Alice's message 

simultaneous transaction; indeed, Alice gets Bob's receipt if in this way. 

and only if Bob gets information from which he can retrieve 35 Should one prefer to trust the Post OfiBce even less, and 

Alice's message. The simultaneity of the transaction is not still enable Bob to prove which message he got from Alice, 

afifected by the order in which the Post OfiBce sends the it sufiBces, for instance, that Alice makes use of digital 

encrypted message to Bob and the receipt to Alice. What signatures; e.g., she sends z=Ey>c>(SIG^(ICM, B, E^m))) in 

matters is that it sends both of them or none, or that Step AI, and the Post OfiBce sends SIG^(ICM, B, E^(m)) 

functionally equivalent steps are taken to preserve simulta- 40 preferably further signed and encrypted — to Bob in Step 

neity. POl. This way, by revealing m, Bob can prove via Alice's 

Alice's receipt certifies that her message was properly signature that she indeed sent him m by extended certified 

sent to Bob, but not the fact that Bob actually received it. mail. 

The Post OfiBce is indeed trusted with properly sending The electronic sending-receipt method is superior to tra- 

messagcs and this can be construed to include that these 45 ditional certified mail in another respect. Alice's receipt 

messages sent by the Post OfiBce reach their destinations. needs not to be a generic one, but enables her to prove the 

But receiving a piece of mail (i.e. having a letter deposited exact content of the message she sent Bob. In fact, if her 

in the right mailbox or having an electronic message reach receipt consists of the Post OflBce *s digital signature that it 

the right computer) may not mean that the recipient is aware has sent z=E^(A, B, Ej,(m)) to Bob, by revealing m she 

of the delivery. It is this awareness that is necessary in many 50 enables anyone to compute v«E^(m) from Bob's public 

scenarios, such as many legal applications. This is why the encryption key, and thus Epq{Al, B, v) from the Post OfiBce 's 

present method is called a sending-receipt method. ITie public encryption key, so as to verify that the result is indeed 

method thus is the electronic equivalent, of traditional cer- z, the value signed by the Post OfiBce. 

tified mail, without return receipt. The ICM is superior to other electronic methods for 

The electronic nature of the method, however, requires 55 certified mail in many respects. In particular, simultaneity is 

some special care, such as a proper customization step. guaranteed, rather than being just highly probable. 

Indeed, in traditional electronic mail, it is easy to achieve Moreover, since the Post OfiBce provides Alice with her 

that an enemy cannot send to Bob the same message Alice receipt. Bob cannot decide whether or not to accept a 

docs, because, if he does not know this message a priori, he message from her based on the sender's identity, 

is prevented from copying by the envelope containing it. 60 It is recommended that each transmission occur within the 

E^(m), however, is a kind of envelope that prevents under- encryption layer of its immediate recipient, (e.g., in Step AI, 

standing m, but can be copied. Indeed, if Alice sends Ejj(m) it is preferable that Alice sends £^^3(510^(1 CM, B, E^i^m))) 

to Bob without customization and an enemy intercepts her rather than SIG^(ICM, B, E^(m)).) Among other things, this 

transmission, he may easily send the same cipherlext E^m) way of transmitting denies an enemy monitoring such trans- 

to Bob (by certified mail or not), creating various potential 65 missions valuable information, such as sender-receiver 

problems. Iliis has been a recognized problem in cryptog- information. Thai is, if an enemy learns E^SIG/,c(ICM, B, 

raphy in different contexts. Notice that having Alice just sign Eg{m))), the transmission of the Post OfiBce to Bob of Step 
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POl, and it further knows that this value was travelling from Alice *s message to Bob in the proper manner, generating the 

the Post OfiBce to Bob, it may deduce that Bob is the proper receipts. These receipts may then be given by the 

recipient of a piece of certified mail, but it may not easily agents to Alice directly, or to the (or some other) entity, who 

learn that the sender was Alice because this piece of data is then will give them (or suflBciently many of them, or a 

protected under Bob's encryption key. Indeed, the Post 5 consolidated version of some of them) to Alice. 

OfiBce may make this harder by processing its POl steps It is also useful that the Post Office agents possess pieces 

relative to different senders and recipients in a different of a secret key of the Post Office. In this case one may wish 

order. If at every time interval there are sufiBciently many that they collaborate for decrypting some communications 

senders, this will confuse the enemy even more. In addition, sent to the Post Office in an encrypted manner. If some of 

the Post Office may arrange for dummy transmissions, so as 10 these communications are intended for someone else (e.g., if 

to have sender traffic that always looks reasonably busy. This one such communication consists of or includes Ea(m) 

enables it to process real and fake sending request in an encrypted with the Post Office' key), then the Post Offices 

interwoven order without creating any delays. If desired, agents may enable directly the recipient to decrypt the 

however, most recipient-encryption protections could be communication (e.g., they may enable only Bob to recon- 

dispensed with. 15 struct E^m). This may be achieved, for instance, by a proper 

Finally, the reference to m as the message Alice wants to use of threshold cryptosystems. Indeed, if single agents are 

send to Bob should be broadly construed to mean any incapable of understanding messages encrypted with the 

message that Alice has for Bob, including a message that is Post Office's key, it may be unnecessary for Alice to first 

chosen before the transaction, but arises or is implicitly encrypt her message m to Bob with Bob's key. She may 

defined by the transaction. 20 directly encrypt m with such a multi-party controlled key of 

Variants and Improvements. Many variants of the the Post Office, the agents of the Post OfiBce will then enable 

above and following methods are applicable and within the Bob to decrypt m, while the agents and/or the Post Office 

scope of the invention. In particular, customization may be will give Alice a proper receipt. A single or sufficiently few 

dismissed all together or achieved by means of other elec- agents of the Post Office will not, however, be able to 

tronically transmissible methods. UTie sender's identity may 25 understand m. 

be used for customization purposes, but hidden from the Another improvement is the following. In the Sending- 

recipienl in some applications. Alice's message may not be Receipt Method Bob may claim that he did not "really" 

hidden from the Post Office, (e.g., if this is a machine, or receive Alice's message because he lost his decryption key. 

consists of a collection of individuals, many of which must To solve this problem, the Post Office may perform the 

cooperate to learn the message). Also, digital signatures 30 Retum Mail Service only for those users who guarantee to 

should be broadly construed to include any form of elec- back up their secret decryption keys in a deemed acceptable 

tronically transmissible guarantees. Conventional encryp- way; so that, for instance, such a Bob may not use his having 

tions may be used in alternative or in conjunction with lost his secret key as a defense against an unwanted piece of 

public-key one. A higher level of interaction may be adopted certified mail. For example, to be ehgible to receive a piece 

in our methods (e.g., if one wishes to get additional valuable 35 of ICM, it can be required that Bob performs (or that he has 

benefits, such as zero-knowledge). In particular, each of our have already performed) a given key-escrow procedure 

Steps can be realized by means of more rounds of commu- relative to his keys used for electronic certified mail pur- 

nications. Time information may be included in some or all poses. This way. Bob may always be capable of retrieving 

of the transmissions, each party may be a multiplicity of his secret key. 

parties, and so on. 40 To create further incentive for Bob to undergo this key- 

Proper use of time information may be important. For escrow step, it may be stipulated that a user cannot be a 

instance, assume Alice specifies (preferably in an untamper- sender of an ICM system, unless he also is a potential 

able way) to the Post Office the time in which her string was receiver with a properly backed up key. In any case, the Post 

sent. If the Post Office receives it too late (or too early), it Office (or a court if and when it is invoked) may regard Bob 

may not send any communication to Bob nor any receipt to 45 as a legitimate receiver if he had given a suitable and timely 

Alice. (Indeed, if the certified message from Alice to Bob is indication that he accepts a given key of his to be used for 

an order to buy stock that day. Bob may not be responsible ICM purposes. 

for failing to obey the order if he got it unreasonably late.) Alternatively, Bob may be regarded to be a legitimate 
Alternatively, the Post Office may specify in its communi- recipient of a piece of ICM by the mere fact that a key of his 
cation to Bob the time when this was sent, preferably in a so is known to be suitably backed up (e.g., by an approved 
digitally signed manner, so that, among other things. Bob key-escrow method), and it was this key of his to be used as 
may in many contexts prove that he got Alice's message too the recipient-key in a ICM transaction. 'ITie fact that Bob has 
late. The Post Office may also deny Alice her receipt if her elected a key of his to be usable as a recipient-key for ICM 
AI transmission arrives too late, or it may issue her a purposes, of the fact that a key of his is suitably backed up, 
properly "time-stamped" receipt, but such receipt may be 55 may, for instance, be part of a certificate of this key (e.g., of 
deemed void for certain purposes if some of the time the certificate showing that this key belongs to Bob), 
information indicated is deemed to be too late. Alternatively, Bob may coincide for ICM purposes with a 
Multiplicities of parties may also be quite useful. For plurality of entities each having a piece of "his" decryption 
instance, Alice may deal with two or more Post Offices for key, so that sufficiently many of these entities may recovery 
delivering the same message to Bob. In this case, having two 60 any message encrypted with Bob's encryption key. Thus, the 
independent receipts for the same message constitutes a Post Office may communicate with each or sufficiently- 
much greater evidence that at least one of the Post Offices many of these entities, 

has properly sent the message to Bob. Alternatively, if, as described above, the Post Office has 

Alternatively, Alice may conveniently deal with a single several agents so as to offer a service based on a type of 

Post Office, but this is an entity comprising or coordinating 65 threshold cryptosystem and messages are not further 

several agents. Such an entity may give Alice's communi- encrypted with a recipient key, there is no worry that the 

cation to two or more of its agents, and these will send recipient may lose his key. Indeed, it will be the Post Office 
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who will enable him to gel his message from Alice. Notice 
also that a weaker customization of Alice's message to Bob 
may be realized within Bob*s encryption layer, or even 
solely within this layer. 

For instance, Alice may send to the Post OfiBce Zs=E^c»(w), 5 
where w-Ej3(A, B, m) or (w«E^(SlG^(m))), just to give an 
example of an alternative customization in this setting. In 
this setting, the message received by Bob is conventionally 
declared to be m only if w is an encryption of (A, B, m), that 
is, if it identifies in some standard way Alice as the sender 
and Bob as the recipient. For instance, if Bob is a stock- 
broker and m a purchaser order of a given stock, if v does 
not consist of A, B, m. Bob is not obliged to buy that stock. 
This way of proceeding facilitates the job of the Post OfiBce 
(for instance because it may not be asked to check any 
customization) and still offers valuable protection. 
The Return-Receipt Method 

Despite its utility, the Sending-Receipt Method suffers 
from the following problem: Bob may never receive (or 
claim not to have received) Alice's (cleartext) message, not 
because he lost (or claims to have lost) his decryption key, 
but because he never got (or claims to have not gotten) any 
communication from the Post OfiBce. For instance, if a 
computer network is iised for communicating during an ICM 
transaction, a failure may occur or may claimed to have 
occurred. 

To solve such problems, the Sending-Receipt Method is 
augmented as follows. After receiving the communication of 
Step POl, Bob may be asked or required to send a proper 
receipt back. This receipt may be sent to the Post OfiBce (or 
directly to Alice, since at that point Bob may have akeady 
learned Alice's identity). Such receipt, if obtained, simplifies 
matters a great deal, and oflPers much greater guarantees to 
everyone involved. Upon receiving it, the Post Office may 
store it, or send it to Alice as an additional receipt, or issue 
to Alice an equivalent additional receipt. 

Alternatively, the Post Office may withhold Alice's 
receipt of Step POl, and give it to her only if Bob does not 
produce any receipt for the Post Office's POl transmission 
to him. Moreover, if Bob does not produce a receipt, the Post 
OfiBce may take some of the actions described below that 
enable it to obtain a receipt from Bob in some other manner 
or enable it to produce a suitable afifidavit (e.g., that Bob 
willingly refused Alice's message). It is expected that Bob 
will readily acknowledge the Post Office POl transmis.sion 
most of the times. Indeed ' he knows that Alice gets a 
sending receipt anyway, and that the Post Office will obtain 
a receipt from him (or issue a suitable affidavit) anyway. 

Moreover, it can be arranged that eligible recipients in the 
ICM systems can incur additional charges if alternative 
actions to obtain a receipt from them are taken. 

In the method just described. Bob is required to produce 
a receipt after he learns Alice's message, and her identifier 
if so wanted. The return-receipt method below, instead, 
elicits a receipt from Bob before he knows the message or 
the sender's identity. Nonetheless, the new receipt may still 
be used, if desired, to prove to third parties the content of 
Alice's message. In describing the preferred embodiment of 
the new return-receipt method, the same computational 
framework of the Sending-Receipt Method is assumed. In 
fact, the first step is identical to that of the Sending-Receipt 60 
Method. 

THE RETURN-RECEIPT METHOD 

Al (Sender Step): Let m be the message that Alice wishes 
to send to Bob in a certified manner, llien she sends the 65 
Post OCBce an encrypted version of m intelligible by 
Bob but not by the Post Office. 
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Her transmission is preferably customized, signed, and 
indicates that it is part of an ICM transaction together 
with other valuable information, such as the trans- 
mission time, (e.g., she send z=Epc>(SIG^(ICM, B, T, 
EB(m))).) POl (Post OfiBce Step): The Post OfiBce 
verifies who is the sender and who is the intended 
recipient, and 

It sends Bob information that determines his message 
without making it yet intelligible to him. 
In so doing the Post OfiBce preferably hides Alice's 
identify, alerts Bob that he is dealing with an ICM 
transaction, and makes use of digital signatures, 
(e.g., it sends Bob y=Ep(5(SIGp^(ICM, recipient: 
B, z)) or ICM, SIG^o(E5(B, z))). 
It also sends Alice a guarantee that it has done so. 
Preferably, in so doing it also specifies other valuable 
information, such as time information T (e.g., it 
sends Alice the value x«E^(SIGpo(z» T).) 
Bl (Recipient Step): Bob sends the Post Ofifice a receipt 
that he got the above transmission, (e.g., he sends 
Epc>(w), where w=SIG^(recipient, z)). 
Possibly, Bob's receipt also indicates other valuable 
information. 

P02 (Post OfiBce Step): If Bob sends back the proper 
receipt within a specified amount of time, then the Post 
Office 

1. sends Alice a suitable receipt; for instance, EA(w), 
and 

2. sends Bob information that enables him to recon- 
struct Alice's message (e.g., E^m)). 

If Alice has signed her transmission to the Post Office 
in Step Al (e.g., she has sent the value z envisaged 
above), then it is preferable that the Post Office 
also enables Bob to guarantee the content of the 
message (e.g., it send Bob SIG^(ICM, B, T, 
E^(m))). 

If Bob does not send back the proper receipt to the Post 
Office within a given amount of time, then the Post Office 
may either do nothing (in which case the only form of 
receipt in Alice's possession is what she has received from 
the Post Ofifice in Step POl); or inform Alice that it has 
received no receipt from Bob; or make a record that no 
receipt has been sent by Bob; or 

P03 takes action to deliver Alice's message to Bob in a 
way that is guaranteed to produce a return-receipt (e.g., 
it delivers the message to Bob by means of traditional 
certified mail). The thus obtained return receipt (or an 
affidavit that Bob refused willingly the mail) is then 
sent to Alice. 

The above ICM transaction is a (logically) simultaneous 
one, and one that hides the identity of sender for as long as 
necessary. 

The same variants and modifications for the Sending- 
Receipt Method can also be applied to the above method. 
Other variants may also be applied. In particular, the 
sending- receipt given by the Post Office to Alice in step POl 
may never be sent (e.g., because it may become irrelevant 
once Alice gets a return-receipt), or sent only if Bob docs not 
produce a return-receipt fast enough. Also, the Post Office 
may receive a transmission from Alice before it performs its 
P02 step. For instance, if Alice sends Eyfig(m) in Step Al, 
she is required to remove her encryption layer before Step 
PO). 

If Bob receives the value z sent to him by the Post Office 
and properly acknowledges it (i.e., if all 
involved — including the. communication network — behave 
properly), the Return-Receipt Method is most efficient. 
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convenient and economical, since, in particular, it can be It should be understood that the present invention can be 
inaplemented in a pure electronic manner. In the Return- used to achieve additional properties, so as to yield other 
Receipt Method, Bob has even more incentives to produce electronic transactions or make simultaneous other elec- 
his receipt than in the above modification of the Sending- tronic transactions. For instance, the present ICM methods 
Receipt Method. Indeed, for instance, while Alice may get 5 may be used to simultaneously sign contracts, 
a proper sending-receipt anyway that can prove the content ^s for another example, it should also be appreciated that 
ol her message to him, if Bob refused to issue his better t^e ICM methods also yield very effective auctions methods 
receipt he wiU not even read the cleartext^ ^ith many bidding procedures (e.g., "public" or "secret- 
he sender s identity. Thus, while Alice already has a good biddings). Indeed, Alice may be a bidder, Bob an entity 
form of receipt, by refusing to collaborate he has absolute . av \u / a a- u *u - c.J 
nothine! 10 handling the bids (e.g., deciding who are the winners of the 

Despite the fact that Bob will almost always produce his f}t ^""^ P"^''/ ^""Z ""'"^ 

receipts, the following are some practical ways to implement ^ ^ ^^^^l^,*^^ ^^igned to each bidder, and 

Step P03. Here, the Post Office aims at delivering m to Bob ^ ^")' message m for Alice to Bob is Alice's bid. 

in exchange for a receipt. Because the Post Office will not in ^^^"^ ^^^hes to place her bid in return of a proper receipt, 

general know m, it suffices that it delivers EB(m), or a string ^5 preferably one that can be used to prove (among other 

encompassing it. Without intending any restrictions, assume information, such as time information) the exact value of her 

that the Post Office aims in Step P03 at delivering the value bid. This way, if necessary, she can contest the "victory" of 

z=Epo(SIGp<5(ICM, A, B, T, E5(m))), envisaged in Step Al someone else. By means of our envisaged mechanisms for 

and sent in digital form via a computer network. ICMs (in particular, of time information, encryption, and 

Tobegin with, as discussed the delivery of z may occur by 20 signatures), we can implement auctions in many different 

some version of traditional certified mail. For instance, the ways. Without any limitation intended, let us illustrate two 

Post Office may print z on paper and then traditionally possible implementations of two simple-minded auctions: 

certified-mail deliver it to Bob, via a "mailman" which may one where the bidding process is "public" and one where it 

or may not work for the Post Office (e.g., he may belong to is "secret." 

UPS, Federal Express or other agency). The return-receipt 25 Consider first the following example of public bidding 

obtained this way does not guarantee the content of the (which may occur, for instance, in a computer network), 

message, however, it may guarantee it in an indirect, yet Assume there is a single indivisible good for sale in the 

adequate, way. For instance, it can be used in conjunction auction, which will be assigned by a process combining both 

with a proper receipt of the Post Office (e.g., a digital price and time. For making things cleaner, let us assume that 

signature of z sent to Alice in Step POl) to provide evidence 30 there is a sequence of times T^,T2, . . . and T^,V^, . . . where 

of the message actually delivered to Bob. T.-^T^e.g. T~T,+A, where A is a fixed quantity.) A bidder 

This format of z may be inconvenient, and thus create an gets the goods for a price P if there is an index/such that she 

extra incentive for Bob to issue a receipt in Step Bl. has offered a price P within time T^. and no higher price has 

Nonetheless, even this formal of z may enable Bob to been offered by time T,. (It is thus advisable that T,- be 

recover m: for instance, he may scan it (with character 35 greater than T., so that there is sufficient time to process all 

recognition) and then to put it into digital form prior to bids properly.) 

decrypting. The current status of the bid can be made available (e.g.. 

More conveniently, the Post Office may store z in a by Bob), so that the bidders know what the highest offered 

computer diskette and have it delivered in person to Bob. price, P, at the "current" time, T, is. If Alice is willing to raise 

This form of delivery enables Bob to produce a return- 40 the price, she must do so before it is too late. Since her bid 

receipt that guarantees directly the content. Indeed, upon consists of her message to Bob, and it is assumed that the 

being physically given the diskette. Bob may easily retrieve Sending-Receipt Method is in use, Alice then sends here bid 

z from it and digitally sign it. This signature may then be to the Post Office in Step Al. If this transmission arrives 

given back to the mailman in the same diskette or in a within a useful time (i.e., before some time T), the Post 

different diskette. The mailman may indeed carry with him 45 Office issues her a receipt with an indication of the proper 

a device capable of checking Bob's signature. (This is quite time (interval), and then forwards her bid to Bob. Bob then 

feasible also because for signature checking such a device processes the bids relative to the next time interval (e.g. 

needs not to have access to any special secret). announces the new highest price, or that the auction is over 

Since Bob would be reading the message prior to signing because no one offered more than the previous highest 

it, it may be preferable to elicit first from Bob an ordinary 50 price). 

generic receipt prior to giving him the diskette (in any case. As can be seen, the Post office may in this application be 

the mailman can sign an affidavit that Bob accepted the an entity cooperating with Bob, even for only auction 

diskette). purposes. Nonetheless, it may be preferable that it be made 

Alternatively, the diskette may contain not z, from which sufficiently independent from Bob. For instance, though 

Bob may retrieve easily Alice's message, but information 55 prices are meant to be public, it is useful that bids are 

that pins down the message but does not yet reveal the encrypted with Bob's key, so that the Post office will not 

message to Bob. For instance, the same value y^EpJi^lGp^ know the content of a bid when it issues a receipt. Thus, in 

(ICM, recipient: B, z)) that we have envisaged the Post particular, it cannot be blamed to have refused to issue a 

Office to send Bob in Step POl. Only after Bob digitally receipt (e.g., by claiming that it had arrived too late) in order 

signs y will the mailman enable Bob to retrieve Alice's 60 to favor a particular bidder. On the other hand. Bob, though 

message. For instance, the device carried by the mailman capable to read the bids, is held back from cheating by the 

(preferably in a tamper-proof portion) may release a secret fact that the bidders have been issued valid and very 

key by which Bob can remove the Post Office encryption informative receipts, 

layer. Alternatively, this key (or the right decryption, or The system can be further enhanced so that the identity of 

information sufficient to decrypt anyway) can be sent, upon 65 the bidder is not revealed to Bob (at least as long as the 

a proper signal, to the mailman, his device, or Bob directly auction is going on), but, say, only the price and time 

by a variety of means (e.g., by phone, radio, etc.). information. Also, at each time (interval), rather than mak- 
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ing available just the new highest bid/price, Bob may make 
available all incoming (legitimate) bids, so that the volume 
of bidding is also learned by the bidders. Also, rather than 
processing the incoming bids in batches and in time 
intervals, Bob may process them one at a time (preferably in 
the order they got in) and with individual times, (e.g., he 
may still announce only the currently highest bid with its 
own individual time T, and when a bid with price P and time 
T is announced, and no higher price than P is offered before 
time T+A then the auction is over.) Again, return receipt may 
also be used in this application. 

It should also be noted that if Alice has sent her bid in a 
very timely fashion and has not received any timely receipt 
within a certain lime, then she may still time to take 
additional steps to ensure that her bid is properly delivered. 
Again, having two or more Post Offices, or Post Offices 
comprising a plurality of agents, may be very useful here 
because this enhance her chance of getting at least one valid 
receipt. 

In particular the Post Office agents may be implementing 
a threshold cryptosystem. A plurality of Post Offices or 
multi- agent Post Offices may also benefit Bob, because he is 
better guaranteed that each bid will be properly forwarded to 
him. There may also be more than one Bob, and (each) Bob 
too may comprise several agents. It should be appreciated 
that if there are a multiplicity of agents involved it is also 
possible that Bob and the Post Office coincide, that is, that 
they simply are names for different functions performed by 
the same auctioning entity. 

Notice also that the ICM methods may immediately 
accommodate secret bidding mechanism. Indeed, any of the 
methods above may be used for this purpose. For instance, 
consider batch-processing of bids when there is a single time 
interval Tand a single, disjoint and subsequent time interval 
T'. Then the Post Offices issues receipts only for those bids 
received during T, and forwards all these bids to Bob, but 
only during T. This way, no bid can be learned before the 
right time, unless there is an illegitimate cooperation 
between Bob and the Post Office (or sufficiently many 
agents). In all these scenarios, customization is quite useful 
since it also prevents that an enemy can copy Alice's bid so 
as to be guaranteed that he will win the auction if she does. 

Finally, it should be noticed that the methods extend to 
more complex auctions, (e.g., there may be may goods of 
arbitrary nature — such as airwave bandwidths — , these 
goods may be divisible, and thus, for instance, the highest 
bid may take only a portion of a good, and so on.) In general 
it will be important to also indicate in each bid the particular, 
auction, good, and the like. 

Although the invention has been described in detail, it 
should be appreciated that the scope of the invention is 
limited only, by the following claims. 

What is claimed is: 

1. A method of transmitting a message using a trusted 
party, comprising: 

a sender causing a customized version of the message to 
be provided to the trusted party, the customized version 
of the message having a first portion intelligible to the 
trusted party but not to a recipient of the message and 
a second portion intelligible to the recipient of the 
message but not to the trusted party; 

the trusted party examining the first portion of the cus- 
tomized version of the message to determine the recipi- 
ent; 

the trusted party causing at least the second portion of the 
customized version of the message to be provided to 
the recipient; and 
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the trusted party causing a receipt for the message to be 
provided to the sender, 

2. An electronic communication method comprising: 
sending from a first party a message for a trusted party, the 

message having first and second portions, the first 
portion being intelligible to the trusted party, identify- 
ing a second party as a recipient of the second portion 
and being unintelligible to the second party, the second 
portion being unintelligible to the trusted party and 
intelligible to the second party; and 
receiving by the first party a receipt indicating that the 
second portion of the message was received by the 
second party. 

3. The method of claim 2 wherein the first portion of the 
message is information encrypted to render it unintelligible 
to the second party. 

4. The method of claim 2 wherein the second portion of 
the message is information encrypted to render it unintelli- 
gible to the trusted party. 

5. The method of claim 2 further comprising signing at 
least one of the first and second portions of the message by 
the first party. 

6. The method of claim 2 wherein the receipt includes a 
representation of the second portion of the message. 

7. The method of claim 2 wherein the receipt includes a 
signature of at least the recipient. 

8. The method of claim 2 wherein: 

the second portion includes information which has been 
processed to render it unintelligible to the trusted party 
and intelligible to the second party; and 

the second portion can be reconstructed using the infor- 
mation. 

9. The method of claim 2 wherein an identity of the 
second party is intelligible from the message only by the 
trusted party. 

10. The method of claim 2 wherein an identity of the 
second party is intelligible from the receipt only by the first 
party. 

11. An electronic communication method comprising: 
receiving by a trusted party a message from a first party, 

^Jie^^giessagCfi^iSg^ 
portioniheinpintelhgoblKto^tK^^ 
C^ing:a:secWd^pai^y-as2a;;Te^ 
{parid:being4miHtlUigible-to-the-second'partyftli^ 
{23)ordon-bemg3ninintelUgible~loZthe~ 

intelligible to the second party; 
sentogaby^the^tFusted-party-the-second-portion-of-'th^^ 

|m6Ssag e-tQ"thc-second- party^^and^ 
serjdin^>Hthp2truged^ 

indicatLng4hat*the^message-wasdeli\^e:d~t0'the.sec 
^arty?^'''^ ~~ 

12. The method of claim 11 wherein the first portion of the 
message is information encrypted to render it unintelligible 
to the second party. 

13. The method of claim 11 wherein the second portion of 
the message is information encrypted to render it unintelli- 
gible to the trusted party, 

14. The method of claim 11, wherein the message includes 
the first party's signature of at least one of the first and 
second portions of the message, 

15. The method of claim 11 wherein: 

the second portion is information which has been pro- 
cessed to render it unintelligible to the trusted party and 
intelligible to the second party; and 

the message can be reconstructed using the information. 

16. llie method of claim 11 wherein an identity of the 
second party is intelligible from the message only by the 
trusted party. 
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17. The method of claim 11 wherein an identity of the 
second party is intelligible from the receipt only by the first 
party. 

18. The method of claim 11 wherein sending the second 
portion of the message to the second parly includes signing 
at least the second portion of the message with the trusted 
party's signature. 

19. The method of claim 18 wherein sending the second 
portion of the message to the second party further comprises 
processing the signed second portion to render it intelligible 
to the second party but unintelligible to at least one party 
other than the second party. 

20. TTie method of claim 11 wherein the receipt includes 
a representation of the second portion of the message. 

21. The method of claim 11 wherein the receipt includes 
a signature of at least the recipient. 

22. The method of claim 11 wherein sending the second 
portion of the message to the second party by the tmsted 
party comprises: 

generating by the trusted party a processed message 
which determines the second message but which is 
unintelligible to the second party; 

sending the processed message to the second party by the 
trusted party; 

receiving by the trusted parly a receipt indicating that the 
second party received the processed message; and 

sending the second message to the second party in a form 
intelligible to the second party. 
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23. The method of claim 22 wherein the processed 
message can be reconstructed from the second message. 

24. The method of claim 22 wherein the receipt indicating 
that the second party received the processed message 

5 includes a signature of the second party. 

25. An electronic communication method comprising: 
receiving by a receiver a first message from a trusted 

parly, the message having a portion normally intelli- 
gible to the receiver which has been processed to render 
it unintelligible to the receiver; 

sending by the receiver a receipt for the message to the 
trusted party; and 

receiving by the receiver a second message from the 
35 trusted party, the second message including the portion 
intelligible to the receiver. 

26. The method of claim 25, wherein the receipt can be 
reconstructed using the portion of the second message 
intelligible to the receiver. 

20 27. The method of claim 25, wherein the first message is 
intelligible to the trusted party. 

28. The method of claim 25, wherein sending the receipt 
includes signing the first message by the receiver. 

29. The method of claim 28, wherein sending the receipt 
25 further includes processing the receipt to render it intelli- 
gible to the trusted party but unintelligible to at least one 
other party. 

ii * 1^ * 
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[57] ABSTRACT 

A public key cryptosystem with roaming user capability 
within a network that allows secure communication between 
users of the system, client machines, and encryption servers. 
A client machine generates and stores an encrypted private 
key on an encryption server. A user may then access the 
encrypted private key from any client machine located on 
(he network and decrypt it using a passphrase, thus giving 
the user roaming capability. The private key may then be 
used to decrypt any encrypted messages received.,4jUser^S'' 
«genefate«aniifitM*ffi^agepeneiypt«itftwithaaidien^^2gj 
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PUBLIC KEY CRYPTOSYSTEM WITH their personal computer at home. In the current age of 

ROAMING USER CAPABILITY "roaming email" and other roaming communication, the 

technology is readily available for users to check their 

TECHNICAL FIELD OF THE INVENTION messages almost anywhere; in the world. If the users do not 

T,. . . 1. . rj . 5 have their private key with them, they cannot retrieve their 

-nils mvention relates m general to encryption of data m ,f ^^^^ ' .^^^^ ^.^^ ^^^^ 

communication systems^In particular, this mvention relates ^^ile traveling, there is the risk that the private key may be 

to a system and n^ethod for managing pubhc/pnvate key j^^^ stolen Furthermore, it is not always easy or conve- 

pairs withm a cryptosystem havmg roammg user capability. ^-^^^ ^^^^ ^^^^^^ ^ J ^.^^^^ ^^^^ ^.^^ 

BACKGROUND OF THE INVENTION ^^^^ quickly integrates with other digital hardware 

worldwide. 

Encrypted voice and data communication systems arc 
well known in the art. These cryptosystems allow a user to 

digitally transmit information to one or more system users The present invention provides a system and method for 

without it being intercepted and interpreted. This is accom- 15 transmitting;^secure-dgi^lielectromc-messag^ 

plished by encrypting and decrypting the transmitted infor- munication channels in a way that substantially eliminates or 

mation with what is known as an encryption key. Encryption reduces disadvantages and problems associated with previ- 

keys may be secret keys, where a single key is utilized for ously developed cryptosystems. 

encryption and decryption, or public keys, where two or More specificaUy, the present invention provides a system 

more keys are used. 20 and method for providing a public key cryptosystem having 

Cryptosystems which utilize secret keys and public keys roaming user capability. The pubUc key cryptosystem with 

are well known in the art. Each type of cryptosystem roaming user capability comprises a network having mul- 

provides some degree of privacy and authentication for liple client computers and multiple encryption servers. The 

digital communications. Secret-key cryptosystems utilize network allows secure communication between the client 

the traditional method known as symmetric key cryptogra- computers and the encryption servers, 

phy. In a symmetric key cryptosystem, a single electronic In one embodiment, the client computer executes a New 

key is used both to encrypt and decrypt the transmitted User computer program and an Enabler computer program 

information. Since only one key is used, the sender must to facilitate secure communication, <!B,Qtfethe:^New ::Useai 

provide the receiver with the key by some form of secure computer program and the Enabler computer program com- 

com munication. The lack of a secure channel, which is munigatg- mt h - ^ 

usually why encryption is used in the first place, makes this cnci^rari^ser^^f>^ 

system mostly obsolete in common practice these days, municates^^^^gi^h^ll^cr^m^ 

Public-key cryptosystems, also referred to as asymmetric <ip^^^^^^t^Syi^iipOise^iaeatifiir^^ 

cryptosystems, provide another means of encrypting infor- ^phrasc;r3^P"priv^c^ke>^ ^ 

mation. Such cryptosystems differ from secret-key crypto- ^ pa^h^0sg,-3;yieldin^^an^ 

systems in that two or more keys are required as opposed to tfahsmittedi^itj rtfaC put^lic key-tb^the-encr-v^^ 

one. In a pubhc-key cryptosystem, each entity has a private ThcTEnabler^^copoputer-pro 

key and a public key. Public keys are generally held in Server^^coS^mcPpfofiram^to^enable^a^^^^ 

databases run by "Key Certificate Authorities" and arc ctejy,pie4;^fii ^bm6ssa ges3scnL ^7,him _^^ ^,and~send^ 

publicly known. However, each user's private key is known enq^^^^^^t|ljn^agesno^tl^^^{srTo read encrypted 

only by that user. Once a sender encrypts a message with a digital messages sent to a user, the user is first prompted for 

recipient's public key, it can only be decrypted using that a passphrase, ^IIh ^p.assRhrase.is,theDHb ashed3andHransDaitted^ 

recipient's private key. Because the computational power tGnhe^en^xPliPil:S^i^erAr-=au 

required to break a key increases exponentially with the pa^^ rase is authentic a|edg:he,jncry 

length of key, longer keys provide greater security. the'us^'fnc^ie3^>^'te^ computer. 

Private keys are usually between 512 and 4096 bits long, ^heresit-is^e<3P>q)ted:^23e^^^^ 

far too long for the average person to commit to memory. tQ:re¥d5aay^dig UaLme^ages1Kc^^ 

For this reason, most users of a public key cryptosystem The Enabler computer program and the Server computer 

store their private key on a personal computer or other jq program also work in conjunction to send encrypted digital 

personal device. The problem with this practice is that messages. Once a digital message is generated, it is 

private key may be lost if the computer software crashes or encrypted with a client recipient's public key. The encrypted 

computer hardware fails. In most cases, the user may have message is then transmitted to the client recipient computer, 

not "backed up" their data. This situation occurs more often The present invention provides an important technical 

than is convenient. In the event that the user wrote down the 55 advantage by providing a way to securely store a user's 

private key in a "safe" place and then lost it, the result is the private key on an encryption server by symmetrically 

same. encrypting it with a passphrase so that no one but the user 

If or when this private key is lost or stolen, and thus has access to it. 

compromised, a complicated "Key Revocation" process Th& present invention provides another important techni- 

occurs. The user must perform the embarrassing task of go cal advantage by providing a way to securely store a user's 

informing all other users with whom he or she coramuni- private key on an encryption server so a user may access the 

cates with that the public/private key pair is no longer valid, private key from any client machine on the encryption server 

and provide them with a new public key to use instead. network, thus providing roaming capability. 

Another major drawback with current public key crypto- The present invention provides another important techni- 

systems is that the users must have their private key with 65 cal advantage by providing a way to access an encrypted 

them to read any of their messages. 'ITiis becomes a problem private key from any client machine on a network by simply 

when the user is traveling and the private key is stored on remembering a user passphra.se. 
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The present invention provides another important techni- DETAILED DESCRIPTION OF THE 

cal advantage by providing a way to store an encrypted INVENTION 

private key on an encryption server instead of the user's n r j u -j- * r*i. . • n 

f. , ''^ . . , r.u • 1 • Preierred embodiments of the present invention are illus- 

chent machine, thus preventing the loss of the private key in T7ir^iTDr?c n i u • j* r . 
^. 4 .u r * u- u f -1 . trated m the FIGURES, hke numerals being used to refer to 

the event the client machine crashes or fails. 5 ,., , j- r • j • 

like and corresponding parts of the vanous drawings. 

-nie present invention provides another important techni- ^ ^^^^^ embodiment of the public key crypto- 

ca advantage by limiting the number of times a user may try ^^^^^ ^ j^^. 200 of the preL^nt 

to log-m to the network per hour so a hacker cannot break ^^^^^^.^^ ^^^^^ ^ communication network system 1000 

into the system and retrieve the user s encrypted pnvate key. comprising an encryption server 105 connected to a network 

The present mvenlion provides another important techni- of multiple client machines 110 through communication 

cal advantage by providing a user friendly pubUc key channels 115 which may each be comprised of a secure 

cryptosystem where the user need not understand how to socket layer. The public cryptosystem with roaming user 

generate, send, or receive a public/private key pair since all capability 200 may have a firewall or any other security 

this is handled by the New User computer program, Enabler devices placed between the encryption server 105 and the 

computer program and the Server computer program. client machines 110 to further secure the encryption server 

BRIEF DESCRIPTION OF THE DRAWINGS ^'""^ ^^'"^ hacked or broken into. 

FIG. 2 shows a client machine 110 which can comprise 

For a more complete understanding of the present inven- incoming and outgoing communication channels 115, a 

tion and the advantages thereof, reference is now made to memory 205, and one or more processors 210, such as 

the following description taken in conjunction with the microprocessors or digital signal processors. Memory 205 

accompanying drawings in which like reference numerals can include any storage medium, including RAM, a hard 

indicate like features and wherein: drive, and tape memory. The processors 210 are electrically 

FIG. 1 shows one embodiment of a communications connected to the memory 205 and have access to a New User 
network system comprising an encryption server, multiple 25 computer program 215 and an Enabler computer program 

client machines, multiple users, and communication chan- 220. The New user computer program 215 and Enabler 

nels in accordance with the invention; computer program 220 may be downloaded from the 

FIG. 2 shows a diagram of a client machine comprising encryption server 105 and stored in memory 205 of client 

incoming and outgoing communication channels, a New machine 110 or directly installed in the memory 205 of client 
User computer program, an Enabler computer program, 30 machine 110 from some other source. Both the New User 

memory, and processors; computer program 215 and Enabler computer program 220 

FIG, 3 shows a diagram of an encryption server compris- communicate with a Server computer program located in 

ing incoming and outgoing communication channels, a New meniory 305 of the encryption server 105. One example of 

User computer program, an Enabler computer program, a ^ ^^^^^^ machine 110 is an IBM compatible computer, 
Server computer program, memory, processors, and a data- 35 however, it should be understood that the client machine 110 

base having a plurality of encrypted private keys, public ^e any communication unit which contains input and 

keys, user identifiers and hashed passphrases; ^^^put communication channels 115, memory 205, and 

FIG. 4 shows a system diagram of an encryption server processors 210, 

downloading a New User computer program, running the F^^. 3 shows an encryption server 105 which may corn- 
New User computer program on a client machine, and 40 prise input and output communication channels 115, a 

transmitting an encrypted private key and public key back to memory 305, a database 315, and one or more processors 

the encryption server in accordance with this invention; ^10, such as microprocessors or digital signal processors. 

FIG. 5 shows a flow chart detaiUng the functions per- database 315 may comprise a plurality of encrypted 

formed by the New User computer program in accordance P"^^^^ ^^y^ .^^O* ^ Pj^^^^ity of public keys 325, a plurality 

with this invention- identifiers 330 and a plurality of hashed passphrases 

^ , ' * J- c.u f 1 • 335. 'Ilie user identifiers could be a log-in ID, or a pass- 

FIG. 6 shows a system diagram of the process of loggmg- , ™ ^.g^ 1 * ■ 1 1 . 1 . 

. , ? \ ..J phrase. The processors 310 are electncally connected to the 

m to the encryption server from a client machine, down- ^^S , , .0 . 

1 J- .u c ui * * .u 1- . u- memory 305 and have access to a Server computer program 

oading he Enabler ajmpuier program to the client machine, 335 gewer computer program 335 may be divided into 

transmitting a hashed passphrase to the encryption server, , i_ r™. it . 
, .J ■ 1 J , J- 50 two or more subprograms. The New User computer program 

downloading the encrypted pnvate key, downloading a j ui * u -j . 

. ,^ . ,. J J , J. 215 and an Enabler computer program 220 may be resident 

client recipient s public key, and generating and sendmg an ins T -.i / .1. i- . 

, J. , . • . on the encryption server 105 and accessible by the chent 

encrypted digital message to the encryption server m accor- a%X 1 r - 

A '.u *I • *• machines 110. One example of an encryption server 105 is 

dance with the invention; c c c* *• e u u ij u a . j »i. * 

a Sun Spare Station 5, however, it should be understood that 

HG. 7 shows a flow chart detailing the functions per- ^he encryption server 105 can be any communication unit 

formed by the Enabler computer program m accordance ^^ich contains input and output communication channels 

with this mvention; 115^ ^^^^^^ 3^5^ processors 310. 

HG. 8 shows another embodiment of a communications pjc. 4 shows one embodiment of the public key crypto- 

network comprising an encryption server, a plurahty of system with roaming user capability 200 where a user may 

client machines, and a public/private key server located access a web page on the client machine 110 and download 

outside the communications network. the New User computer program 215 to the client machine 

FIG. 9 shows another embodiment of a communications 110 from the encryption server 105. The New User computer 

network comprising an encryption server, a pop server, and program 215 may also be downloaded from a server outside 

a client machine containing a pop proxy; and the network 1000 or directly loaded on to the client machine 

FIG. 10 shows a network comprising multiple encryption 65 110 from another source. ITie New user computer program 

servers all connected to each other through communication 215 directs the client machine 110 to generate a user 

channels. identifier 330, a private key, and a public key 325. The New 
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User computer program 215 then encrypts the private key 
and transmits the encrypted private key 320 and public key 
325 back to the encryption server 105. The Server computer 
program 335 directs the encryption server 105 to receive the 
encrypted private key 320 and the public key 325 from the 5 
client machine 110 and store them in the encryption server 
105 database 315. 

FIG. 5 shows the steps performed by one embodiment of 
the New User computer program 215 working in conjunc- 
tion with the Server computer program 335. The user first 
accesses an encryption server 105 from the client machine 
110 as stated in step 505. llie encryption server 105 may be 
accessed from the client machine 110 through an encryption 
server 105 web page. The user then downloads the New User 
computer program 215 from the encryption server 105 to the ^5 
client machine 110 in step 510. At steps 515, 520 and 525 
respectively, the New User computer program 215, which 
may be written in a number of different computer languages 
including JAVA, generates a user identifier 330, private key, 
public key 325, and prompts the user for a user passphrase. 20 
The user may choose his own passphrase or let the New user 
computer program 215 generate it for him. True random 
numbers needed to facilitate key generation may be actively 
or passively generated by the user during this time. The New 
user computer program 215 then communicates with the 25 
Server computer program 335 and compares the hash of the 
user passphrase against a large database of hashed English 
words, hashed common nouns, and hashed popular sayings 
to assure that the hash of the passphrase chosen cannot be 
easily guessed in step 530. If the passphrase is determined 30 
to be easily gucssable, the user has the option to either keep 
the passphrase or generate a new one. The New User 
computer program 215 then encrypts the private key with 
the passphrase in step 535. The private key may be 
encrypted with a number of different ciphers, including a 35 
symmetrical cipher such as Blowfish or DES. In step 540, 
the encrypted private key 320 and public key 325 are then 
transmitted to the encryption server 105. Finally, the Server 
computer program 335 stores the encrypted private key 320 
and public key 325 on the encryption server 105 in step 545, 40 
In another embodiment, the New User computer program 
215, the Enabler computer program 220, the encrypted 
private key 320, and other user preference information may 
be stored on the client machine 110 as well as transmitting 
and storing it on the encryption server 105 to save download 45 
transmission time. 

By storing the encrypted private key 320 on the encryp- 
tion server 105, the user enjoys some added benefits. First, 
the user may access and download the encrypted private key 
320 from any client machine 110 on the network 1000, thus 50 
giving the user roaming capability. Second, storing the 
encrypted private key 320 on the encryption server 105 
eliminates the need for the user to remember or carry his or 
her private key. All the user needs to remember to access the 
encrypted private key 320 is a passphrase. This is consid- 55 
erably easier than remembering a private key which may be 
as large as 2,048 bits. Third, since the user*s private key is 
stored on the encryption server 105 in encrypted form, only 
the user may retrieve and decrypt the private key. Neither an 
encryption server 105 administrator nor anyone else would 60 
be able to decrypt the private key. 

FIG. 6 shows one embodiment of the public key crypto- 
system with roaming user capability 200 depicting the 
process by which a client machine 110 transmits a digital 
message to the encryption server 105. First, the user logs-in 65 
to the encryption server 105 in step 605. Here, the server is 
authenticated to the user by industry standard means, such as 
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SSL using authentication certificates. For security purposes, 
a user may be limited to a certain number of log-in sessions 
per hour, such as forty, to prevent someone from trying to 
break into the network 1000 and obtain a user's encrypted 
private key 320. The encryption server 105 then downloads 
the Enabler computer program 220 to the client machine 110 
in step 610. The user then enters his or her passphrase, 
hashes the passphrase, and transmits the hashed passphrase 
to the encryption server 105 in step 615. In step 620, the 
encryption server 105 authenticates the hashed passphrase 
and transmits the encrypted private key 320 back to the 
client computer 110. In step 625, the user may decrypt the 
encrypted private key 320 with his or her passphrase, 
generate a digital message, and obtain a message recipient's 
pubhc key 325 from the encryption server 105. Finally, in 
step 630, the user may encrypt the digital message with the 
recipient's public key 325, optionally signing the digital 
message with the client sender's private key, and transmit 
the encrypted digital message to the encryption server 105. 
All public keys 325 of message recipients may be tempo- 
rarily or permanently stored on the client machine 110 for 
speed in future message sending. 

Once the encrypted digital message is stored on the 
encryption server 105, the client recipient to whom the 
encrypted digital message is directed may retrieve and 
decrypt the encrypted digital message with his private key. 
The digital message may be email, real-time chat, or any 
other form of digital message which may be transmitted over 
the network 1000. 

In another embodiment, the encrypted digital message 
does not have to be stored on the encryption server 105, but 
may instead be transmitted in any convenient way to the 
digital message recipient. For real time data that is time or 
bandwidth sensitive, (e.g., real time voice communication) 
encrypted digital message data may flow directly between 
both communicating client machines 110. The encryption 
server 105 is only necessary for user key storage. 

In the process depicted in FIG. 6, the user passphrase, 
plaint text private key, or encrypted private key 320 remains 
on the client machine 110 only for the duration of time in 
which the user is logged- in to the network 1000. As soon as 
the user logs-off of the network 1000, the passphrase is 
erased from the client machine 110, 

In another embodiment, the user passphrase, or private 
key may not be erased after logging-off the network 1000. 
In this embodiment, the user passphrase or private key 
remain on the computer so the user rarely has to retype their 
passphrase or download the encrypted private key 320 from 
the encryption server 105. The user passphrase or plain text 
private key, are never transmitted to the encryption server 
105. 

FIG. 7 details the functions performed by one embodi- 
ment of the Enabler computer program 220 working in 
conjunction with the Server computer program 335. In step 
705, the Enabler computer program 220 first prompts the 
user for a passphrase. The passphrase is then hashed and 
transmitted to the encryption server 105 in steps 710 and 
715. The Server computer program 335 authenticates the 
hashed passphrase and transmits the encrypted private key 
320 back to the client machine 110 in steps 720 and 725. The 
Server computer program 335 may also transmit other user 
information from the encryption server 105 to the client 
machine 110. In step 730, the Enabler computer program 
220 then decrypts the encrypted private key 320 at the client 
machine 110. At this point, the user may use his or her 
private key to access his or her digital mcvssages. 
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The Enabler computer program 220 also allows the user 
to generate a digital message and obtain a recipient's public 
key 325 from the encryption server 105 as shown in step 735 
and 740. Finally, in steps 745 and 750, the Enabler computer 
program 220 encrypts the digital message with a chent 5 
recipient public key 325 and transmits the encrypted digital 
message to the encryption server 105. A cyclic redundancy 
check (CRC) may be added to the end of the digital message 
before encrypting it for added security. A couple of examples 
of ciphers which may be used to encrypt the digital message 
are the standard RSA cipher or the DifQe-Helman cipher. 

FIG. 8 shows another embodiment of the public key 
cryptosystem with roaming user capability 1000 where the 
client machines CI and C2 may communicate with a public 
key server 805 located outside the network 1000. The 
encryption server 105 may also communicate with the 
public key server 805 through communication channel 815. 
Communication with the public key server 805 is made 
possible through a Translator program which may be stored 
on the encryption server 105. First, a user may download the 20 
Enabler computer program 220 to client machine CI. The 
user may then execute the Enabler computer program 220 
and transmit an encrypted digital message from client 
machine CI to the public key server 805 through commu- 
nication channels 810. A user of client machine C2 may then 2$ 
retrieve the digital message from the public key server 805, 
download the Enabler computer program 220 from the 
encryption server 105, and decrypt the retrieved encrypted 
digital message. 

FIG, 9 shows another embodiment of the public key 30 
cryptosystem with roaming user capability 200 where a user 
transmits and receives digital messages through a pop proxy 
910. This embodiment comprises an encryption server 105, 
a cHent machine 110 containing a pop proxy 910, and a pop 
server 905. A user first downloads a pop proxy 910 appli- 35 
cation to his or her client machine 110. The pop proxy 910 
is then installed and configured to be the pop address that 
client machine 110 connects to. The pop proxy 910 is 
connected to and communicates directly with a pop account 
located on pop server 905 through communication channel 4Q 
915. The pop proxy 910 is also connected to the encryption 
server 105 through communication channels 115 and has 
access to both the New User computer program 215 and the 
Enabler computer program 220. 

Once the pop proxy 910 is installed and configured on the 45 
client machine 110, the user may access a web page on the 
client machine 110 and download the New User computer 
program 215 to the pop proxy 910 from the encryption 
server 105. The New user computer program 215 directs the 
client machine 110 to generate a user identifier 330, a private 50 
key, and a public key 325. The New User computer program 
215 then encrypts the private key and transmits the 
encrypted private key 320 and public key 325 back to the 
encryption server 105. The Server computer program 335 
directs the encryption server 105 to receive the encrypted 55 
private key 320 and the public key 325 from the client 
machine UO and store them in the encryption server 105 
database 315. 

To transmit a digital message from the system depicted in 
FIG. 9, the user first logs-in to the encryption server 105. 60 
Here, the server is authenticated to the user by industry 
standard means, such as SSL using authentication certifi- 
cates. For security purposes, a user may be limited to a 
certain number of log-in sessions per hour, such as forty, to 
prevent someone from trying to break into the network 1000 65 
and obtain a user's encrypted private key 320. llie encryp- 
tion server 105 then downloads the Enabler computer pro- 
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gram 220 to the pop proxy 910. The user then enters his or 
her passphrase, hashes the passphrase, and transmits the 
hashed passphrase to the encryption server 105. 

Next, the encryption server 105 authenticates the hashed 
passphrase and transmits the encrypted private key 320 back 
to the client computer 110. The user may now decrypt the 
encrypted private key 320 with his or her passphrase, 
generate a digital message, and obtain a message recipient's 
pubhc key from the pop server 905. Finally, the user may 
encrypt the digital message with the recipient's public key, 
optionally signing the digital message with the client send- 
er's private key, and transmit the encrypted digital message 
to the pop server 905. All pubHc keys of message recipients 
may be temporarily or permanently stored on the pop proxy 
910 for speed in future message sending. 

Once the encrypted digital message is stored on the pop 
server 905, the pop server 905 client recipient to whom the 
encrypted digital message is directed may retrieve and 
decrypt the encrypted digital message with his private key. 
^rhe digital message may be email, real-time chat, or any 
other form of digital message which may be transmitted over 
the network 1000. 

In another embodiment, the encrypted digital message 
does not have to be stored on the pop server 905, but may 
instead be transmitted in any convenient way to the digital 
message recipient. For real time data that is time or band- 
width sensitive, (e.g., real time voice communication) 
encrypted digital message data may flow directly between 
both communicating client machines 110. 

In the process depicted in FIG. 6, the user passphrase, 
plaint text private key, or encrypted private key 320 remains 
on the pop proxy 910 only for the duration of time in which 
the user is logged-in to the network 1000, As soon as the user 
logs-off of the network 1000, the passphrase is erased from 
the pop proxy 910. 

In another embodiment, the user passphrase, or private 
key may not be erased after logging-off the network 1000. 
In this embodiment, the user passphrase or private key 
remain on the computer so the user rarely has to retype their 
passphrase or download the encrypted private key 320 from 
the encryption server 105. The user passphrase or plain text 
private key, are never transmitted to the encryption server 
105. 

FIG. 10 shows another embodiment of the public key 
cryptosystem with roaming user capability 200 where the 
network 1000 comprises multiple encryption servers 105 
which all communicate with each other through communi- 
cation channels 1010. An example of an encryption server 
105 may be a Sun Workstation, or a low cost personal 
computer operating on a Unix system, contain all or a subset 
of every user's encrypted private key 320, pubUc key 325, 
user identifier 330, or other user information. In this 
embodiment, the encryption server 105 administrator may 
have access to the private keys specific to each encryption 
server 105 on the network 1000, 

Although the present invention has been described in 
detail, it should be understood that various changes, substi- 
tutions and alterations can be made hereto without departing 
from the spirit and scope of the invention as described by the 
appended claims. 

What is claimed is: 

1. A system for sending an encrypted digital message<froiTii 
a user at#aW51ieot sender computer 4to*P£lic5t recipient 
computer over a network, comprising: 

a client computer operable to access an Enabler computer 
program, said client computer comprising: 
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a client memory operable to store said Enabler com- English words, common nouns, and popular sayings 

puter program; located on said database of said encryption server; 

a client processor electrically connected to said client encrypt said private key with said hash of said user 

memory, said client processor operable to execute passphrase yielding said encrypted private key; and 
said Enabler computer program such that said client 5 transmit said encrypted private key and said public key to 

computer is directed by said Enabler computer pro- g^id encryption server. 

gram to communicate with a Server computer pro- 3^ 'phe system of claim 1, wherein said user identifier is a 
gram located on said encryption server to: ^scr log-in ID or said user passphrase, and further wherein 
allow said user to enter a user identifier; said user log-in ID or user passphrase is hashed and trans- 
transmit said user identifier to said encryption server mitted to said encryption server and compared against said 
to verify identity of said user; database of hashed user identifiers to verify the identity of 
receive a private key encrypted with a passphrase said user. 

from a database located in a memory of said 4. 'ITie system of claim 2, wherein said encryption server 
encryption server, said private key having a cor- js further operable to execute said Server computer program 
responding public key forming a public/private to communicate with said New User computer program such 
key pair; ^tiat said encryption server is directed by said Server corn- 
use said passphrase to decrypt said encrypted private puter program to* 

key at said client coniputer, receive and compare said hash of said passphrase against 

retnevea^user recipient s public key; ^ j^^^^ ^^^^^^ ^^^^ ^ ^^^^^^ ^ 

public key; and ^ 

*^ . .V 1 . i encryption server; 

transmit-said-encr-vptcd'digitaLmessagewto said user jii^-.i , • 

■^-i -^^^|~~jr compare said hash of said passphrase against said data- 

' . , . , , base of hashed passphrases to verify the identity of said 
an encryption server, said encryption server operable to 

process requests from said client computer, said . , 

25 receive said encrypted private key and said public key 

encryption server comprismg: . , , .j ^ , • / 1 c -j i- 

ui . ° . . 4 paired to said encrypted private key from said client 

a server memory operable to store said Server computer ^ t • H 

program and a database, said database comprising a compu er, an 

plurality of said user identifiers, encrypted private store said encrypted private key and said public key in 

keys, and public keys; and , database of said encryption server, 

a server processor electronically connected to said 5. The system of claim I wherem said Enabler computer 

server memory, said server processor operable to Program is ftirther executable to transmit other user specific 

execute said Server computer program such that said ^formation from said client computer to said encryption 

encryption server is directed by said Server computer ^^^^ ^^"^^^ computer program is ^rther executable 

program to communicate with said Enabler com- ^"^^^^"^^t other user specific information from said encryp- 

puter program to- server database to said cuent computer. 

£eceivc3nd:xompaf^ ^^^^^"^ ^^^'^ ^^^f ^^^^ ^^^^ °^^y 

.plurality-oLuser4deDtifierslocatrd:iiriiid^daTabas^ ^^^.^"^ computer on said network to access said encrypted 

of:^.eli^i5^1^.er4o-verifydl^ pnvate key, thus giving said user roaming capabihty. 

^^^^jr~-- — ^ " 7. The system of claim 1, wherein said user passphrase 

retrieve said encrypted private key from said encryp- ^^^^^"^ °" ^^j^. ^"^"^ computer for the duration of time said 

tion server database; and "^"^ logged-m to said encryption server, further wherein 

ctransmit^said-encrypted_priyate^&from said ^^^^ passphrase is never transmitted to said encryption 

^■"iSE^^^^toT^^^^^ user^s^elientzcomputeii;, ^'^^^ ^'^^^ ^^^"^ ^^^^ ^^^^^^ computer when said 

^jj^ user logs-off said network, 

.1 . . J T * J 4 -J "^5 8. The system of claim 1, wherein said user passphrase or 

a network comprising said client sender computer, said . , , ^ r ^ • cc 

^ °] 'jv* * pnvate key may not be erased after logeing-off said network, 

encryption server, and said client recipient computer, ^ . , , • . • 1 . . . 

. . -J * 1 11 • L * said user passphrase or said pnvate key remain on said 

wherein said network allows communication between t 

said client sender computer and said encryption server „ \™ ri-i t. ■ -j jj--. 

^ A _*u u * \i *' J -J Ine system 01 claim 1, wherein said encrypted digital 

and further between said encryption server and said . , ... 

i. , . . ^ _ ^ J, u • J * 1 50 message resides on said encryption server and may not be 

client recipient computer; and wherein said network ^ , . , , ... . . - , 

-^^^ „ „^ f^,^ accessed by anyone but an intended user recipient, further 

comprises a plurality ot client computers and encryp- , . * , .. • , , . , ^ ^ 

^- f-«u u' L *' wherein said digital message may be m the form of email or 

tion servers, further wherein each encryption server can , . • . . e> j 

communicate with every other encryption server on m r-nt \ ri-^i- .1 

said network system or claim 1, wherein a secure socket layer 

* ™ , V 1 • 1 u ■ J 1- * ^ . 55 exists between said client sender computer and said encryp - 

2. The system of claim 1, wherein said chent computer is j u • -j 11 ^ - 

r ui * * J XT ir . lion server, and wherein said secure socket layer also exists 

further operable to store and access a New User computer . , . j .j ^ 

, ,1 ^ ^ ^ between said encryption server and said client recipient 

program, said client computer processor operable to execute t 

said New User computer program such that said client ^/ t,' , r 1 ■ -» , . 

computer is directed by said New User computer program to "^^'^"^ °^ '^'^'fl 2 wherein said New User 

communicate with said Server computer program to; «° ^"""P"'" Pf°f ^"Z^"" '^"*!''*^ =°°'P"'" P^^^^^^"" "f^ 

... . , ^ downloaded from said encryption server or are directly 

generate~sail^HHaic/pr.vate.key,paia ^^,^,1,,^ on said client computer. 

generate said user passphrase; The system of claim 1, wherein said private key is 

-generate said user identifier; symmetrically encrypted with said passphrase and stored on 
hash said user passphrase; 55 either said encryption server or said client computer, 

transmit said hash of said user passphrase to said encryp- 13. ^The system of claim 1, wherein said encryption server 

tion server to compare against a plurality of hashed allows a limited number of log-on attempts. 
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14. The system of claim 1, whereio said digital message 
is encrypted using any public/private key cipher including 
RSA, Elliptical Curve, or Diffie-Helman. 

15. The system of claim 1, wherein said encrypted digital 
message is transmitted from said client sender computer to 5 
a server outside said network, then from said server outside 
said network to said client recipient computer 

16. The system of claim 1, wherein each encryption server 
on said network contains all or a subset of every user's 
encrypted private key, pub He key, user identifier, or other 
user information. 

17. The system of claim 16, wherein each encryption 
server of said network has its own public/private key pair, 
further wherein each encryption server has access to said 
public/private key pairs of every other encryption server on 
said network. ^5 

18. The system of claim 17, wherein only an encryption 
server administrator has access to said private keys of each 
encryption server on said network. 

19. The system of claim 1, wherein a cyclic redundancy 
check (CRC) is added to the end of said digital message 20 
before encrypting it. 

20. The system of claim 1, wherein said encryption server 
includes a translator computer program to communicate 
with other public/private key encryption servers operating 
under a different standard certificate of authority. 25 

21. The system of claim 1, wherein said public keys are 
stored on said encryption server in plain text form. 

22. The system of claim 1, wherein said Server computer 
program and said New User computer program are divided 
into two or more subprograms. 30 

23. The system of claim 1, wherein said user passphrase 
is generated by said New User computer program, 

24. The system of claim 1, wherein said passphrase is 
actively or passively generated by true random numbers. 

25. The system of claim 1, wherein said encryption server 35 
is authenticated to said user by industry standard means, 
such as SSL, using authentication certificates. 

26. The system of claim 1, wherein said user may option- 
ally sign said digital message with said private key before 
encrypting and transmitting said digital message to said 40 
encryption server 

27. The system of claim 1, wherein said digital message 
contains time or bandwidth sensitive data, and wherein said 
digital message need not be transmitted through said encryp- 
tion server, and further wherein said time or bandwidth 45 
sensitive data is encrypted and transmitted directly to said 
client recipient computer. 

28. The system of claim 1, wherein said passphrase, 
private key, or said user recipient's public is not erased after 
logging-off said network, and said passphrase, said private 50 
key, or said user recipient public key remains on said 
computer. 

29. A method for sending an encrypted digital message 
from a client sender machine to a client recipient machine 
comprising the steps of: 55 

at said client sender machine: 
entering a user identifier; and 

transmitting:said:iiser:identifi'erito an encryption server; 
at said encryption server: 

receiving said user identifier; 60 

comparing said user identifier against a plurality of user 
identifiers located in a database on said encryption 
server to verify the identity of said user; 

retrieving a private key encrypted with a passphrase 
from said database of said encryption server, said 65 
private key having a corresponding public key, 
thereby forming a public/private key pair; and 



transmitting said encrypted private key from said 
encryption server to said user's client machine; 
at said client sender machine: 

receiving said encrypted private key from said encryp- 
tion server; 

decrypting said encrypted private key with said pass- 
phrase; 

cgenerating-a-digitM:message; 

retrieving a user recipient's public key from said 
encryption server database; 

eacryptingisaidrdigitallmessage.witfilsdd^u^ recipi- 
ent's ^ubliclkejgcand 

it ransmittin g^said''en'crvptecl3ig ital^ messa'ge~ 

client:recipient:macSine;-lrnd' wherein said method 
employs a network comprised of a plurality of client 
computers and encryption servers, further wherein 
each encryption server can communicate with every 
other encryption server on said network. 

30. The method of claim 29, further comprising the 
following steps prior to entering said user identifier, 

at said client sender machine: 

generating said public/private key pair; 

generating said user passphrase; 

generating said user identifier, wherein said identifier 

can be a user log-in ID; 
hashing said user passphrase; 

transmitting said hash of said user passphrase to said 
encryption server to compare against said database 
of hashed English words, common nouns, and popu- 
lar sayings; 

encrypting said private key with said hash of said user 
passphrase yielding said encrypted private key; and 

transmitting said encrypted private key and said public 
key to said encryption server; 
at said encryption server: 

receiving said encrypted private key and said public 
key; and 

storing said encrypted private key and said public key 
in said database of said encryption server. 

31. The method of claim 29, wherein said user identifier 
is said user's passphrase, further wherein said user's pass- 
phrase is hashed and transmitted to said encryption server 
and compared against said database of hashed passphrases to 
verify the identity of said user, 

32. The method of claim 29, wherein said encrypted 
digital message is transmitted from said client sender 
machine to said encryption server, then transmitted from 
said encryption server to said client recipient machine. 

33. The method of claim 29, wherein said encrypted 
digital message is transmitted from said client sender 
machine to a server outside said network then from said 
server outside said network to said client recipient machine. 

34. The method of claim 29, wherein said passphrase is 
actively or passively generated by true random numbers. 

35. The method of claim 29, wherein said user may 
optionally sign said digital message with said private key 
before encrypting and transmitting said digital message to 
said encryption server. 

36. A method for sending an encrypted digital message 
from a client sender machine to a client recipient machine 
comprising the steps of: 

entering a user identifier; and 

transmitting said user identifier to an encryption server to 

verify identity of said user; and 
downloading an Enabler computer program from said 

encryption server to said client sender's machine, 
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wherein said Enabler computer program is executable 

to communicate with a Server computer program 

located on said encryption server to: 

allow said user to enter a user identifier; 

trans^^said user identifier to said encryption server to 
veS^^SeSify^j^sSPu???; 

receive a private key encrypted with a passphrase from 
a database located in a memory of said encryption 
server, said private key having a corresponding pub- 
lic key, thereby forming a public/private key pair; 

use said passphrase to decrypt said encrypted private 
key at said client computer; 

retrieve a user recipient's public key from said encryp- 
tion server database; 

encrypt a digital message with said user recipient's 
public key; and 

transmit said encrypted digital message to said user 
recipient; and wherein said method employs a net- 
work comprised of a plurality of client computers 
and encryption servers, further wherein each encryp- 
tion server can communicate with every other 
encryption server on said network. 

37. The method of claim 36, wherein a New User com- 
puter program is downloaded from said encryption server to 
said client seder's machine, further wherein said New User 
computer program is executable to communicate with a 
Server computer program located on said encryption server 
to: 

generate said public/private key pair; 
generate said user passphrase; 
generate said user identifier; 
hash said user passphrase; 

transmit said hash of said user passphrase to said encryp- 
tion server to compare against a plurality of hashed 
English words, common nouns, and popular sayings 
located on said database of said encryption server; 

encrypt said private key with said hash of said user 
passphrase yielding said encrypted private key; and 

transmit said encrypted private key and public key to said 
encryption server. 

38. The method of claim 36, wherein said user identifier 
is said user's passphrase, further wherein said user's pass- 
phrase is hashed and transmitted to said encryption server 
and compared against said database of hashed passphrases to 
verify the identity of said user. 

39. The method of claim 36, wherein said New User 
computer program and said Enabler computer program are 
directly loaded onto said client sender's machine. 

40. The method of claim 36, wherein logging into said 
encryption server comprises the steps of finding a log-in web 
page for said encryption server on the Internet and typing in 
a user's identifier. 

41. The method of claim 36, wherein said encrypted 
digital message is transmitted from said client sender 
machine to said encryption server, then transmitted from 
said encryption server to said client recipient machine. 

42. A system for sending an encrypted digital message 
from a user at a client sender computer to a client recipient 
computer over a network, comprising: 

a client computer operable to access an Enabler computer 
program, said client computer comprising: 
a client memory operable to store said Enabler com- 
puter program; 
a client processor electrically connected to said client 
memory, said client processor operable to execute 
said Enabler computer program such that said client 
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computer is directed by said Enabler computer pro- 
gram to communicate with a Server computer pro- 
gram located on said encryption server to: 
allow said user to enter a user identifier; 
transmit said user identifier to said encryption server 

to verify identity of said user; 
receive a private key encrypted with a passphrase 
from a database located in a memory of said 
encryption server, said private key having a cor- 
responding public key forming a public/private 
key pair; 

use said passphrase to decrypt said encrypted private 

key at said client computer; 
retrieve a user recipient's public key; 
encrypt a digital message with said user recipient's 

public key; and 
transmit said encrypted digital message to said user 

recipient; 

an encryption server, said encryption server operable to 
process requests from said client computer, said 
encryption server comprising: 

a server memory operable to store said Server computer 
program and a database, said database comprising a 
plurality of said user identifiers, encrypted private 
keys, and public keys; and 

a server processor electronically connected to said 
server memory, said server processor operable to 
execute said Server computer program such that said 
encryption server is directed by said Server computer 
program to communicate with said Enabler com- 
puter program to: 

receive and compare said user identifier against a 
plurality of user identifiers located in said database 
of said encryption server to verify identity of said 
user; 

retrieve said encrypted private key from said encryp- 
tion server database; and 

transmit said encrypted private key from said 
encryption server to said user's client computer; 
and 

a network comprising said client sender computer, 
said encryption server, and said client recipient 
computer, wherein said network allows communica- 
tion between said client sender computer and said 
encryption server and further between said encryp- 
tion server and said client recipient computer; and 
wherein said user passphrase remains on said client 
server computer for the duration of time said user is 
logged-in to said encryption server, 
further wherein said user passphrase is never transmit- 
ted to said encryption server and is erased from said 
client computer when said user logs-off said net- 
work. 

43. A system for sending an encrypted digital message 
from a user at a client sender computer to a client recipient 
computer over a network, comprising; 

a client computer operable to access an Enabler computer 
program, said client computer comprising: 
a client memory operable to store said Enabler com- 
puter program; 
a client processor electrically connected to said client 
memory, said client processor operable to execute 
said Enabler computer program such that said client 
computer is directed by said Enabler computer pro- 
gram to communicate with a Server computer pro- 
gram located on said encryption server to: 
allow said user to enter a user identifier; 
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transmit said user identifier to said encryption server 
to verify identity of said user; 

receive a private key encrypted with a passphrase 
from a database located in a memory of said 
encryption server, said private key having a cor- 
responding public key forming a public/private 
key pair; 

use said passphrase to decrypt said encrypted private 

key at said client computer; 
retrieve a user recipient's public key; 
encrypt a digital message with said user recipient's 

public key; and 
transmit said encrypted digital message to said user 

recipient; 

an encryption server, said encryption server operable to 
process requests from said client computer, said 
encryption server comprising: 

a server memory operable to store said Server computer 
program and a database, said database comprising a 
plurality of said user identifiers, encrypted private 
keys, and public keys; and 

a server processor electronically connected to said 
server memory, said server processor operable to 
execute said Server computer program such that said 
encryption server is directed by said Server computer 
program to communicate with said Enabler com- 
puter program to: 

receive and compare said user identifier against a 
plurality of user identifiers located in said database 
of said encryption server to verify identity of said 
user; 

retrieve said encrypted private key from said encryp- 
tion server database; and 

transmit said encrypted private key from said 
encryption server to said user's client computer; 
and 

a network comprising said client sender computer, said 
encryption server, and said client recipient computer, 
wherein said network allows communication between 
said client sender computer and said encryption server 
and further between said encryption server and said 
client recipient computer; and 
wherein said user passphrase or private key may not be 

erased after logging-off said network. 
44. A system for sending an encrypted digital message 
from a user at a client sender computer to a client recipient 
computer over a network, comprising: 

a client computer operable to access an Enabler computer 
program, said chent computer comprising: 
a client memory operable to store said Enabler com- 
puter program; 
a client processor electrically connected to said client 
memory, said client processor operable to execute 
said Enabler computer program such that said client 
computer is directed by said Enabler computer pro- 
gram to communicate with a Server computer pro- 
gram located on said encryption server to: 
allow said user to enter a user identifier; 
transmit said user identifier to said encryption server 

to verify identity of said user; 
receive a private key encrypted with a passphrase 
from a database located in a memory of said 
encryption server, said private key having a cor- 
responding public key forming a public/private 
key pair; 

use said passphrase to decrypt said encrypted private 
key at said client computer; 
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retrieve a user recipient's public key; 

encrypt a digital message with said user recipient's 

public key; and 
transmit said encrypted digital message to said user 

recipient; 

an encryption server, said encryption server operable to 
process requests from said client computer, said 
encryption server comprising: 

a server memory operable to store said Server computer 
program and a database, said database comprising a 
plurality of said user identifiers, encrypted private 
keys, and public keys; and 

a server processor electronically connected to said 
server memory, said server processor operable to 
execute said Server computer program such that said 
encryption server is directed by said Server computer 
program to communicate with said Enabler com- 
puter program to: 

receive and compare said user identifier against a 
plurality of user identifiers located in said database 
of said encryption server to verify identity of said 
user; 

retrieve said encrypted private key from said encryp- 
tion server database; and 

transmit said encrypted private key from said 
encryption server to said user's client computer; 
and 

a network comprising said client sender computer, said 
encryption server, and said client recipient computer, 
wherein said network allows communication between 
said client sender computer and said encryption server 
and further between said encryption server and said 
client recipient computer; and 
wherein said encrypted digital message resides on said 
encryption server and may not be accessed by anyone 
but an intended user recipient. 
45. A system for sending an encrypted digital message 
from a user at a client sender computer to a client recipient 
computer over a network, comprising: 

a client computer operable to access an Enabler computer 
program, said client computer comprising: 
a client memory operable to store said Enabler com- 
puter program; 
a client processor electrically connected to said client 
memory, said client processor operable to execute 
said Enabler computer program such that said client 
computer is directed by said Enabler computer pro- 
gram to communicate with a Server computer pro- 
gram located on said encryption server to: 
allow said user to enter a user identifier; 
transmit said user identifier to said encryption server 

to verify identity of said user; 
receive a private key encrypted with a passphrase 
from a database located in a memory of said 
encryption server, said private key having a cor- 
responding public key forming a public/private 
key pair; 

use said passphrase to decrypt said encrypted private 

key at said client computer; 
retrieve a user recipient's public key; 
encrypt a digital message with said user recipient's 

public key; and 
transmit said encrypted digital message to said user 

recipient; 

an encryption server, said encryption server operable to 
process requests from said client computer, said 
encryption server comprising: 
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a server memory operable to store said Server computer 
program and a database, said database comprising a 
plurality of said user identifiers, encrypted private 
keys, and public keys; and 

a server processor electronically connected to said 
server memory, said server processor operable to 
execute said Server computer program such that said 
encryption server is directed by said Server computer 
program to communicate with said Enabler com- 
puter program to: 

receive and compare said user identifier against a 
plurality of user identifiers located in said database 
of said encryption server to verify identity of said 
user; 

retrieve said encrypted private key from said encryp- 
tion server database; and 

transmit said encrypted private key from said 
encryption server to said user's client computer; 
and 

a network comprising said client sender computer, said 
encryption server, and said client recipient computer, 
wherein said network allows communication between 
said client sender computer and said encryption server 
and further between said encryption server and said 
client recipient computer; and wherein a secure socket 
layer exists between said cUent sender computer and 
said encryption server, and 
wherein said secure socket layer also exists between said 

encryption server and said client recipient computer. 
46. A system for sending an encrypted digital message 
from a user at a client sender computer to a client recipient 
computer over a network, comprising: 

a client computer operable to access an Enabler computer 
program, said chent computer comprising: 
a client memory operable to store said Enabler com- 
puter program; 
a client processor electrically connected to said client 
memory, said client processor operable to execute 
said Enabler computer program such that said client 
computer is directed by said Enabler computer pro- 
gram to communicate with a Server computer pro- 
gram located on said encryption server to: 
allow said user to enter a user identifier; 
transmit said user identifier to said encryption server 

to verify identity of said user; 
receive a private key encrypted with a passphrase 
from a database located in a memory of said 
encryption server, said private key having a cor- 
responding public key forming a public/private 
key pair; 

use said passphrase to decrypt said encrypted private 

key at said client computer; 
retrieve a user recipient's public key; 
encrypt a digital message with said user recipient's 

public key; and 
transmit said encrypted digital message to said user 

recipient; 

an encryption server, said encryption server operable to 
process requests from said client computer, said 
encryption server comprising: 

a server memory operable to store said Server computer 
program and a database, said database comprising a 
plurality of said user identifiers, encrypted private 
keys, and public keys; and 

a server processor electronically connected to said 
server memory, said server processor operable to 
execute said Server computer program such that said 
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encryption server is directed by said Server computer 
program to communicate with said Enabler com- 
puter program to: 

receive and compare said user identifier against a 
plurahty of user identifiers located in said database 
of said encryption server to verify identity of said 
user; 

retrieve said encrypted private key from said encryp- 
tion server database; and 

transmit said encrypted private key from said 
encryption server to said user's client computer; 
and 

a network comprising said client sender computer, said 
encryption server, and said client recipient computer, 
wherein said network allows communication 
between said client sender computer and said 
encryption server and further between said encryp- 
tion server and said client recipient computer; and 
wherein said encryption server allows a hmited number 
of log-on attempts. 
47. A system for sending an encrypted digital message 
from a user at a client sender computer to a client recipient 
computer over a network, comprising; 

a client computer operable to access an Enabler computer 
program, said client computer comprising: 
a client memory operable to store said Enabler com- 
puter program; 
a client processor electrically connected to said client 
memory, said client processor operable to execute 
said Enabler computer program such that said client 
computer is directed by said Enabler computer pro- 
gram to communicate with a Server computer pro- 
gram located on said encryption server to: 
allow said user to enter a user identifier; 
transmit said user identifier to said encryption server 

to verify identity of said user; 
receive a private key encrypted with a passphrase 
from a database located in a memory of said 
encryption server, said private key having a cor- 
responding public key forming a public/private 
key pair; 

use said passphrase to decrypt said encrypted private 

key at said client computer; 
retrieve a user recipient's public key; 
encrypt a digital message with said user recipient's 

public key; and 
transmit said encrypted digital message to said user 

recipient; 

an encryption server, said encryption server operable to 
process requests from said client computer, said 
encryption server comprising: 

a server memory operable to store said Server computer 
program and a database, said database comprising a 
plurality of said user identifiers, encrypted private 
keys, and public keys; and 

a server processor electronically connected to said 
server memory, said server processor operable to 
execute said Server computer program such that said 
encryption server is directed by said Server computer 
program to communicate with said Enabler com- 
puter program to: 

receive and compare said user identifier against a 
plurahty of user identifiers located in said database 
of said encryption server to verify identity of said 
user; 

retrieve said encrypted private key from said encryp- 
tion server database; and 
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transmit said encrypted private key from said 
encryption server to said user's client computer; 
and 

a network comprising said client sender computer, said 
encryption server, and said client recipient computer, 
wherein said network allows communication 
between said client sender computer and said 
encryption server and further between said encryp- 
tion server and said client recipient computer; and 
wherein said encrypted digital message is transmitted 
from said client sender computer to a server outside 
said network, then from said server outside said 
network to said client recipient computer. 
48, A system for sending an encrypted digital message 
from a user at a client sender computer to a client recipient 
computer over a network, comprising: 

a client computer operable to access an Enabler computer 
program, said client computer comprising: 
a client memory operable to store said Enabler com- 
puter program; 
a client processor electrically connected to said client 
memory, said client processor operable to execute 
said Enabler computer program such that said chent 
computer is directed by said Enabler computer pro- 
gram to communicate with a Server computer pro- 
gram located on said encryption server to: 
allow said user to enter a user identifier; 
transmit said user identifier to said encryption server 

to verify identity of said user; 
receive a private key encrypted with a passphrase 
from a database located in a memory of said 
encryption server, said private key having a cor- 
responding public key forming a public/private 
key pair; 

use said passphrase to decrypt said encrypted private 

key at said client computer; 
retrieve a user recipient's public key; 
encrypt a digital message with said user recipient's 

public key; and 
transmit said encrypted digital message to said user 40 

recipient; 

an encryption server, said encryption server operable to 
process requests from said client computer, said 
encryption server comprising: 

a server memory operable to store said Server computer 45 
program and a database, said database comprising a 
plurality of said user identifiers, encrypted private 
keys, and public keys; and 

a server processor electronically connected to said 
server memory, said server processor operable to 
execute said Server computer program such that said 
encryption server is directed by said Server computer 
program to communicate with said Enabler com- 
puter program to: 

receive and compare said user identifier against a 
plurality of user identifiers located in said database 
of said encryption server to verify identity of said 
user; 

retrieve said encrypted private key from said encryp- 
tion server database; and 

transmit said encrypted private key from said 
encryption server to said user's client computer; 
and 

a network comprising said client sender computer, said 
encryption server, and said client recipient computer, 
wherein said network allows communication 
between said client sender computer and said 



encryption server and further between said encryp- 
tion server and said client recipient computer; and 
wherein a cyclic redundancy check (CRC) is added to 
the end of said digital message before encrypting it. 

49. A system for sending an encrypted digital message 
from a user at a client sender computer to a client recipient 
computer over a network, comprising: 

a client computer operable to access an Enabler computer 
program, said client computer comprising: 
a client memory operable to store said Enabler com- 
puter program; 
a client processor electrically connected to said client 
memory, said client processor operable to execute 
said Enabler computer program such that said client 
computer is directed by said Enabler computer pro- 
gram to communicate with a Server computer pro- 
gram located on said encryption server to: 
allow said user to enter a user identifier; 
transmit said user identifier to said encryption server 

to verify identity of said user; 
receive a private key encrypted with a passphrase 
from a database located in a memory of said 
encryption server, said private key having a cor- 
responding public key forming a public/private 
key pair; 

use said passphrase to decrypt said encrypted private 

key at said client computer; 
retrieve a user recipient's public key; 
encrypt a digital message with said user recipient's 

public key; and 
transmit said encrypted digital message to said user 
recipient; 

an encryption server, said encryption server operable to 
process requests from said client computer, said 
encryption server comprising: 

a server memory operable to store said Server computer 
program and a database, said database comprising a 
plurality of said user identifiers, encrypted private 
keys, and public keys; and 
a server processor electronically connected to said 
server memory, said server processor operable to 
execute said Server computer program such that said 
encryption server is directed by said Server computer 
program to communicate with said Enabler com- 
puter program to: 

receive and compare said user identifier against a 
plurality of user identifiers located in said database 
of said encryption server to verify identity of said 
user; 

retrieve said encrypted private key from said encryp- 
tion server database; and 
transmit said encrypted private key from said 
encryption server to said user's client computer; 
and 

a network comprising said client sender computer, said 
encryption server, and said client recipient computer, 
wherein said network allows communication 
between said client sender computer and said 
encryption server and further between said encryp- 
tion server and said client recipient computer; and 
wherein said encryption server is authenticated to said 
user by industry standard means, such as SSL, using 
authentication certificates. 

50. A system for sending an encrypted digital message 
from a user at a client sender computer to a client recipient 

65 computer over a network, comprising: 

a client computer operable to access an Enabler computer 
program, said client computer comprising: 



10 



15 



20 



25 



30 



35 



50 



55 



60 



01/26/2004. EAST Version: 1.4.1 



6,154,543 



21 



22 



10 



a client memory operable to store said Enabler com- 
puter program; 
a client processor electrically connected to said client 
memory, said client processor operable to execute 
said Enabler computer program such that said client 5 
computer is directed by said Enabler computer pro- 
gram to communicate with a Server computer pro- 
gram located on said encryption server to: 
allow said user to enter a user identifier; 
transmit said user identifier to said encryption server 

to verify identity of said user; 
receive a private key encrypted with a passphrase 
from a database located in a memory of said 
encryption server, said private key having a cor- 
responding public key forming a public/private 
key pair; ^5 
use said passphrase to decrypt said encrypted private 

key at said client computer; 
retrieve a user recipient's public key; 
encrypt a digital message with said user recipient's 

public key; and 20 
transmit said encrypted digital message to said user 
recipient; 

an encryption server, said encryption server operable to 
process requests from said client computer, said 
encryption server comprising: 25 
a server memory operable to store said Server computer 
program and a database, said database comprising a 
plurality of said user identifiers, encrypted private 
keys, and public keys; and 
a server processor electronically connected to said 30 
server memory, said server processor operable to 
execute said Server computer program such that said 
encryption server is directed by said Server computer 
program to communicate with said Enabler com- 
puter program to: 35 
receive and compare said user identifier against a 
plurality of user identifiers located in said database 
of said encryption server to verify identity of said 
user; 

retrieve said encrypted private key from said encryp- 40 

tion server database; and 
transmit said encrypted private key from said 

encryption server to said user's client computer; 

and 

a network comprising said client sender computer, said 45 
encryption server, and said client recipient computer, 
wherein said network allows communication 
between said client sender computer and said 
encryption server and further between said encryp- 
tion server and said client recipient computer; and 50 

wherein said user may optionally sign said digital 
message with said private key before encrypting and 
transmitting said digital message to said encryption 
server. 

51. A system for sending an encrypted digital message ss 
from a user at a client sender computer to a client recipient 
computer over a network, comprising: 

a client computer operable to access an Enabler computer 
program, said client computer comprising: 
a client memory operable to store said Enabler com- 60 

puter program; 
a client processor electrically connected to said client 
memory, said client processor operable to execute 
said Enabler computer program such that said client 
computer is directed by said Enabler computer pro- 65 
gram to communicate with a Server computer pro- 
gram located on said encryption server to: 



allow said user to enter a user identifier; 

transmit said user identifier to said encryption server 
to verify identity of said user; 

receive a private key encrypted with a passphrase 
firom a database located in a memory of said 
encryption server, said private key having a cor- 
responding public key forming a public/private 
key pair; 

use said passphrase to decrypt said encrypted private 

key at said client computer; 
retrieve a user recipient's public key; 
encrypt a digital message with said user recipient's 

public key; and 
transmit said encrypted digital message to said user 

recipient; 

an encryption server, said encryption server operable to 
process requests from said client computer, said 
encryption server comprising: 

a server memory operable to store said Server computer 
program and a database, said database comprising a 
plurality of said user identifiers, encrypted private 
keys, and public keys; and 

a server processor electronically connected to said 
server memory, said server processor operable to 
execute said Server computer program such that said 
encryption server is directed by said Server computer 
program to commimicate with said Enabler com- 
puter program to: 

receive and compare said user identifier against a 
plurality of user identifiers located in said database 
of said encryption server to verify identity of said 
user; 

retrieve said encrypted private key from said encryp- 
tion server database; and 

transmit said encrypted private key from said 
encryption server to said user's client computer; 
and 

a network comprising said client sender computer, said 
encryption server, and said client recipient computer, 
wherein said network allows communication 
between said client sender computer and said 
encryption server and further between said encryp- 
tion server and said client recipient computer; and 

wherein said digital message contains time or band- 
width sensitive data, and wherein said digital mes- 
sage need not be transmitted through said encryption 
server, and further wherein said lime or bandwidth 
sensitive data is encrypted and transmitted directly to 
said cUent recipient computer. 
52. A system for sending an encrypted digital message 
from a user at a client sender computer to a client recipient 
computer over a network, comprising: 

a client computer operable to access an Enabler computer 

program, said client computer comprising: 

a client memory operable to store said Enabler com- 
puter program; 

a client processor electrically connected to said client 
memory, said client processor operable to execute 
said Enabler computer program such that said client 
computer is directed by said Enabler computer pro- 
gram to communicate with a Server computer pro- 
gram located on said encryption server to: 
allow said user to enter a user identifier; 
transmit said user identifier to said encryption server 

to verify identity of said user; 
receive a private key encrypted with a passphrase 
from a database located in a memory of said 
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encryption server, said private key having a cor- 
responding public key forming a public/private 
key pair; 

use said passphrase to decrypt said encrypted private 

key at said client computer; 
retrieve a user recipient's public key; 
encrypt a digital message with said iLser recipient*s 

public key; and 
transmit said encrypted digital message to said user 

recipient; 

an encryption server, said encryption server operable to 
process requests from said client computer, said 
encryption server comprising: 

a server memory operable to store said Server computer 
program and a database, said database comprising a 
plurality of said user identifiers, encrypted private 
keys, and public keys; and 

a server processor electronically connected to said 
server memory, said server processor operable to 
execute said Server computer program such that said 
encryption server is directed by said Server computer 
program to communicate with said Enabler com- 
puter program to: 

receive and compare said user identifier against a 
plurality of user identifiers located in said database 
of said encryption server to verify identity of said 
user; 

retrieve said encrypted private key from said encryp- 
tion server database; and 

transmit said encrypted private key from said 
encryption server to said user's client computer; 
and 

a network comprising said client sender computer, said 
encryption server, and said client recipient computer, 
wherein said network allows communication 
between said client sender computer and said 
encryption server and further between said encryp- 
tion server and said client recipient computer; and 

wherein said passphrase, private key, or said user 
recipient's public key is not erased after logging-off 
said network, and said passphrase, said private key, 
or said user recipient public key remains on said 
computer. 

53. A method for sending an encrypted digital message 
from a client sender machine to a client recipient machine 
comprising the steps of: 

at said client sender machine: 
entering a user identifier; and 

transmitting said user identifier to an encryption server; 
at said encryption server: 
receiving said user identifier; 

comparing said user identifier against a plurality of user 
identifiers located in a database on said encryption 
server to verify the identity of said user; 

retrieving a private key encrypted with a passphrase 
from said database of said encryption server, said 
private key having a corresponding public key, 
thereby forming a public/private key pair; and 

transmitting said encrypted private key from said 
encryption server to said user's client machine; 
at said client sender machine: 

receiving said encrypted private key from said encryp- 
tion server; 

decrypting said encrypted private key with said pass- 
phrase; 

generating a digital message; 

retrieving a user recipient's public key from said 
encryption server database; 
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encrypting said digital message with said user recipi- 
ent's public key; and 

transmitting said encrypted digital message to said 
client recipient machine; and 

wherein said user identifier is said user's passphrase, 
further wherein said user's passphrase is hashed and 
transmitted to said encryption server and compared 
against said database of hashed passphrases to verify 
the identity of said user. 

54. A method for sending an encrypted digital message 
from a client sender machine to a client recipient machine 
comprising the steps of: 

at said client sender machine: 
entering a user identifier; and 

transmitting said user identifier to an encryption server; 
at said encryption server: 
receiving said user identifier; 

comparing said user identifier against a plurality of user 
identifiers located in a database on said encryption 
server to verify the identity of said user; 

retrieving a private key encrypted with a passphrase 
from said database of said encryption server, said 
private key having a corresponding public key, 
thereby forming a public/private key pair; and 

transmitting said encrypted private key from said 
encryption server to said user's client machine; 
at said client sender machine; 

receiving said encrypted private key from said encryp- 
tion server; 

decrypting said encrypted private key with said pass- 
phrase; 

generating a digital message; 

retrieving a user recipient's public key from said 
encryption server database; 

encrypting said digital message with said user recipi- 
ent's public key; and 

transmitting said encrypted digital message to said 
client recipient machine; and 
wherein said user encrypted digital message is transmitted 

from said client sender machine to said encryption 

server, then transmitted from said encryption server to 

said client recipient machine. 

55. A method for sending an encrypted digital message 
from a client sender machine to a client recipient machine 
comprising the steps of: 

at said client sender machine: 
entering a user identifier; and 

transmitting said user identifier to an encryption server; 
at said encryption server; 
receiving said user identifier; 

comparing said user identifier against a plurality of user 
identifiers located in a database on said encryption 
server to verify the identity of said user; 

retrieving a private key encrypted with a passphrase 
from said database of said encryption server, said 
private key having a corresponding public key, 
thereby forming a public/private key pair; and 

transmitting said encrypted private key from said 
encryption server to said user's client machine; 
at said client sender machine: 

receiving said encrypted private key from said encryp- 
tion server; 

decrypting said encrypted private key with said pass- 
phrase; 

generating a digital message; 

retrieving a user recipient's public key from said 
encryption server database; 
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encrypting said digital message with said user recipi- 
- ent's public key; and 

transmitting said encrypted digital message to said 
client recipient machine; and 

wherein said encrypted digital message is transmitted 
from said client sender machine to a server outside 
said network then from said server outside said 
network to said client recipient machine. 

56. A method for sending an encrypted digital message 
from a client sender machine to a client recipient machine 
comprising the steps of: 

at said client sender machine: 
entering a user identifier; and 

transmitting said user identifier to an encryption server; 
at said encryption server: 
receiving said user identifier; 

comparing said user identifier against a plurality of user 
identifiers located in a database on said encryption 
server to verify the identity of said user; 

retrieving a private key encrypted with a passphrase 
from said database of said encryption server, said 
private key having a corresponding public key, 
thereby forming a public/private key pair; and 

transmitting said encrypted private key from said 
encryption server to said user's client machine; 
at said client sender machine: 

receiving said encrypted private key from said encryp- 
tion server; 

decrypting said encrypted private key with said pass- 
phrase; 

generating a digital message; 

retrieving a user recipient's public key from said 
encryption server database; 

encrypting said digital message with said user recipi- 
ent's public key; and 

transmitting said encrypted digital message to said 
client recipient machine; and 

wherein said user may optionally sign said digital 
message with said private key before encrypting and 
transmitting said digital message to said encryption 
server. 

57. A method for sending an encrypted digital message 
from a client sender machine to a client recipient machine 
comprising the steps of: 

entering a user identifier; and 

transmitting said user identifier to an encryption server to 

verify identity of said user; and 
downloading an Enable r computer program from said 

encryption server to said client sender's machine, 

wherein said Enabler computer program is executable 

to communicate with a Server computer program 

located on said encryption server to: 

allow said user to enter a user identifier; 

transmit said user identifier to said encryption server to 
verify identity of said user; 

receive a private key encrypted with a passphrase from 
a database located in a memory of said encryption 
server, said private key having a corresponding pub- 
lic key, thereby forming a public/private key pair; 

use said passphrase to decrypt said encrypted private 
key at said client computer; 

retrieve a user recipient's public key from said encryp- 
tion server database; 

encrypt a digital message with said user recipient's 
public key; and 
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transmit said encrypted digital message to said user 
recipient; and 

wherein a New User computer program is downloaded 
from said encryption server to said client sender's 
machine, further wherein said New User computer 
program is executable to communicate with a Server 
computer program located on said encryption server 
to: 

generate said public/private key pair; 
generate said user passphrase; 
generate said user identifier; 
hash said user passphrase; 

transmit said hash of said user passphrase to said 
encryption server to compare against a plurality of 
hashed English words, common nouns, and popu- 
lar sayings located on said database of said 
encryption server; 

encrypt said private key with said hash of said user 
passphrase yielding said encrypted private key; 
and 

transmit said encrypted private key and public key to 
said encryption server, 

58. A method for sending an encrypted digital message 
from a client sender machine to a client recipient machine 
comprising the steps of: 

entering a user identifier; and 

transmitting said user identifier to an encryption server to 

verify identity of said user; and 
downloading an Enabler computer program from said 

encryption server to said client sender's machine, 

wherein said Enabler computer program is executable 

to communicate with a Server computer program 

located on said encryption server to: 

allow said user to enter a user identifier; 

transmit said user identifier to said encryption server to 
verify identity of said user; 

receive a private key encrypted with a passphrase from 
a database located in a memory of said encryption 
server, said private key having a corresponding pub- 
lic key, thereby forming a public/private key pair; 

use said passphrase to decrypt said encrypted private 
key at said client computer; 

retrieve a user recipient's public key firom said encryp- 
tion server database; 

encrypt a digital message with said user recipient's 
public key; and 

transmit said encrypted digital message to said user 
recipient; and 

wherein said New User computer program and said 
Enabler computer program are directly loaded onto 
said client sender's machine. 

59. A method for sending an encrypted digital message 
from a client sender machine to a client recipient machine 
comprising the steps of: 

entering a user identifier; and 

transmitting said user identifier to an encryption server to 
verify identity of said user; and 

downloading an Enabler computer program from said 
encryption server to said client sender's machine, 
wherein said Enabler computer program is executable 
to communicate with a Server computer program 
located on said encryption server" to: 
allow said user to enter a user identifier; 
transmit said user identifier to said encryption server to 
verify identity of said user; 
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receive a private key encrypted with a passphrase from 
a database located in a memory of said encryption 
server, said private key having a corresponding pub- 
lic key, thereby forming a public/private key pair; 

use said passphrase to decrypt said encrypted private ^ 
key at said client computer; 

retrieve a user recipient's public key from said encryp- 
tion server database; 



28 

encrypt a digital message with said user recipient's 
public key; and transmit said encrypted digital mes- 
sage to said user recipient; and 

wherein said encrypted digital message is transmitted 
from said client sender machine to said encryption 
server, then transmitted from said encryption server 
to said client recipient machine, 

* * * * 
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ABSTRACT 



A method for verifying the authenticity of messages 
exchanged between a pair of correspondents in an electronic 
conducted over a data transmission system where the cor- 
respondents each include respective signing and verifying 
portions of a first signature scheme and a second signature 
scheme different from the first and utilizing an elliptic curve 
cryptosystem. 

8 Claims, 2 Drawing Sheets 
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DATA CARD VERIFICATION SYSTEM 

This invention relates to methods and apparatus for data 
transfer and authentication in an electronic transaction 
system, and more particularly to electronic transaction sys- 5 
tems utilizing smart cards. 

BACKGROUND OF THE INVENTION 

It has become widely accepted to conduct transactions 
such as financial transactions or exchange of documents 
electronically. Automated teller machines (ATMs) and credit 
cards are widely used for personal transaction and as their 
use expands so loo does the need to verify such transactions 
increase. A smart card is somewhat like a credit card and 
includes some processing and storage capability. Smart 
cards are prone to fraudulent misuse, for example by a 
dummy terminal which is used to glean information from an 
unsuspecting user. Thus, before any exchange of critical 
information takes place between either a terminal and a 
smart card or vice versa it is necessary to verify the 
authenticity of the terminal as well as the card. One of these 
verifications may take the form of "signing" an initial 
transaction digitally so that the authenticity of the transac- 
tion can be verified by both parties involved in the subse- 
quent session. The signature is performed according to a 
protocol that utilizes a random message, i.e. the transaction 
and a secret key associated with the party. 

The signature must be performed such that the party's 
secret key cannot be determined. To avoid the complexity of 
distributing secret keys, it is convenient to utilize a public 
key encryption scheme in the generation of the signature. 
Such capabilities arc available where the transaction is 
conducted between parties having access to relatively large 
computing resources, but it is equally important to facilitate 
such transactions at an individual level where more limited 
computing resources available, as in the smart card. 

Transaction cards or smart cards are now available with 
limited computing capacity, but these are not suflBcient to 
implement existing digital signature protocols in a commer- 
cially viable manner. As noted above, in order to generate a 4Q 
verification signature it is necessary to utilize a public key 
inscription scheme. Currently, most public key schemes are 
based on RSA, but the DSS and the demand for a more 
compact system are rapidly changing this. The DSS scheme, 
which is an implementation of a Diffie-Hellman public key ^5 
protocol, utilizes the set of integers Zp where p is a large 
prime. For adequate security, p must be in the order of 512 
bits, although the resultant signature may be reduced mod q, 
where q divides p-1, and may be in the order of 160 bits. 

An alternative encryption scheme which was one of the 50 
first fully fledged public key algorithms and which works for 
encryption as well as for digital signatures is known as the 
RSA algorithm. RSA gets it security from the ditEculty of 
factoring large numbers. The public and private keys are 
functions of a pair of large (100 to 200 digits or even larger) 55 
of prime numbers. The public key for RSA encryption is n, 
the product of the two primes p and q where p and q must 
remain secret and e which is relatively prime to (p-l)x(q- 
1), the encryption key d is equal to e"^ (mod(p-l)x(q-l)). 
Note that d and n are relatively prime. gg 

To encrypt a message m, first divide into a number of 
numerical blocks such that each block is a unique represen- 
tation modulo n, then the encrypted message block c,. is 
simply m,-'' (mod n). To decrypt a message take each 
encrypted block c^. and compute m,=c,-'' (mod n). 55 

Another encryption scheme that provides enhanced secu- 
rity at relatively small modulus is that utilizing elliptic 
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curves in the finite field 2'". A value of m in the order of 155 
provides security comparable to a 512 bit modulus DSS and 
therefore offers significant benefits in implementation. 

DifEe-Hellman public key encryption utilizes the proper- 
ties of discrete logs so that even if a generator p and the 
exponentiation is known, the value of k cannot be 
determined. A similar properly exist with elliptic curves 
where the addition of two points on any curve produces a 
third point on the curve. Similarly, multiplying a point P on 
the curve by an integer k produces a further point on the 
curve. For an elliptic curve, the point kP is simply obtained 
by adding k copies of the point P together. 

However, knowing the starting point and the end point 
does not reveal the value of the integer k which may then be 
used as a session key for encryption. The value kP, where P 
is an initial known point is therefore equivalent to the 
exponentiation P*". Furthermore, elliptic curve crypto- 
systems offer advantages over other key crypto-systems 
when bandwidth efi5ciency, reduced computation and mini- 
mized code space are application goals. 

Furthermore, in the context of a smart card and an 
automated teller machine transaction, there are two major 
steps involved in the authentication of both parlies. The first 
is the authentication of the terminal by the smart card and the 
second is the authentication of the smart card by the termi- 
nal. Generally, this authentication involves the verification 
of a certificate generated by the terminal and received by the 
smart card and the verification of a certificate signed by the 
smart card and verified by the terminal. Once the certificates 
have been positively verified the transaction between the 
smart card and the terminal may continue. 

Given the limited processing capability of the smart card, 
verifications and signature processing performed on the 
smart card are generally limited to simple encryption algo- 
rithms. A more sophisticated encryption algorithm is gen- 
erally beyond the scope of the processing capabilities con- 
tained within the smart card. Thus, there exist a need for a 
signature verification and generation method which may be 
implemented on a smart card and which is relatively secure. 

SUMMARY OF THE INVENTION 

This invention seeks in one aspect to provide a method of 
data verification between a smart card and a terminal. 

In accordance with this aspect there is provided a method 
for verifying a pair of participants in an electronic 
transaction, comprising the steps of verifying information 
received by the second participant from the first participant, 
wherein the verification is performed according to a first 
signature algorithm; verifying information received by the 
firsl participant from the second participant, wherein the 
verification is performed according to a second signature 
algorithm; and whereby the transaction is rejected if either 
verification fails. 

The first signature algorithm may be one which is com- 
putationally more difficult in signing than verifying, while 
the second signature algorithm is more difficult in verifying 
than signing. In such an embodiment the second participant 
may participate with relatively little computing power, while 
security is maintained at a high level. 

In a further embodiment, the firsl signature algorithm is 
based on an RSA, or DDS type algorithm, and the second 
signature algorithm is based on an elliptic curve algorithm, 

BRIEF DESCRIPTION OF THE DRAWINGS 

An embodiment of the invention will now be described by 
way of example on the reference to the accompanying 
drawings, in which. 
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FIG. la is a schematic representations showing a smart 
card and terminal; 

FIG. \b is a schematic representations showing the 
sequence of events performed during the verification process 
in a smart card transaction system; and 5 

FIG. 2 is a detailed schematic representation showing a 
specific protocol. 

DETAILED DESCRIPTION OF A PREFERRED 

EMBODIMENT iq 
Referring to FIG. 1(a), a terminal 100 is adapted to 
receive a smart card 102. Typically, insertion of the card 102 
into the terminal initiates a transaction. Mutual authentica- 
tion between the terminal and the card is then performed as 
shown in FIG. lb. In very general terms, this mutual 15 
authentication is performed according to a "challenge - 
response" protocol. Generally, card transmits information to 
the terminal, the terminal 100 signs information with an 
RSA based algorithm 112 and is then sent to the card 102, 
which verifies the information with an RSA based algorithm 20 
114. The information exchange 116 between the card and the 
terminal also includes information generated by the card 
which is sent to the terminal to be signed by the terminal 
with an RSA algorithm and returned to the card to be verified 
utilizing a RSA algorithm. Once the relevant verification has 25 
been performed 118, a further step is performed where 
information is signed by the card using an elliptic curve 
encryption protocol 120 and submitted to the terminal to be 
verified 124 by the terminal utilizing an elliptic curve based 
protocol. Similarly, the information exchange 122 between 30 
the card and the terminal may include information generated 
by the terminal which is sent to the card to be signed by the 
card and returned to the terminal for verification. Once the 
appropriate information has been verified 126 the further 
transactions between the terminal and card may proceed 35 
128. 

Referring now to FIG. 2, a detailed implementation of the 
mutual authentication of the terminal and the card, accord- 
ing to the "challenged-response" protocol is shown gener- 
ally by numeral 200. The terminal 100 is first verified by the 
card 102 and the card is then verified by the terminal. The 
terminal first sends to the card a certificate C^, 20 containing 
its ID, Tjr^, and public information including the public key. 
The certificate 20 may be also signed by a certifying 
authority (CA) so that the card may verify the association of 
the terminal ID T^^ with the public key received from the 
terminal. The keys used by the terminal and the CA in this 
embodiment may both be based on the RSA algorithm. 

With the RSA algorithm each member or party has a 
public and a private key, and each key has two parts. The 
signature has the form: 

S=m'^{mod n) 

where: 

m is the message to be signed; 55 

n a public key is the modulus and is the product of two 
primes p and q; 

e the encryption key chosen at random and which is also 
public is a number chosen to be relatively prime to (p-l)x 
(q-1); and 60 

d the private key which is congruent to e"^ (mod(p-l)x 

(q-i))- 

For the RSA algorithm, the pair of integers (n,e) are the 
public key information that is used for signing. While, the 
pair of integers (d,n) may be used to decrypt a message 65 
which has been encrypted with the public key information 
(n,e). 



Referring back to FIG. 2, the numbers n and e are the 
public keys of the CA and may be set as system parameters. 
The public key e may be either stored in the smart card or 
in an alternate embodiment hardwired into an logic circuit in 
the card. Furthermore, by choosing e to be relatively small, 
ensures that the exponentiation may be carried out relatively 
quickly. 

The certificate 20 C^ is signed by the CA and has the 
parameters (n,e). The certificate contains the terminal ID T^^. 
and the terminal public key information T„ and T^ which is 
based on the RSA algorithm. The certificate Cj is verified 24 
by the card extracting T^^,, T„, T^. This information is simply 
extracted by performing C/ mod n. The card then authen- 
ticates the terminal by generating a random number Rl, 26, 
which it transmits to the terminal. The terminal signs the 
message Rl using its secret key T^ by performing Rl^' 
MODT„ to generate the value Cj, 28. Once again the key 
used by the terminal is an RSA key which has been origi- 
nally created in such a way that the public key T^ consist of 
a small possibly system wide parameter having a value 3, 
while the other part of the public key is the modulus T„ 
which would be associated with the terminal. The terminals 
private key T^ cannot be small if it corresponds to a small 
public key T^. In the case of the terminal, it does not matter 
whether the private key T^ is chosen to be large as the 
terminal has the required computing power to perform the 
exponentiation relative quickly. 

Once the terminal has calculated the value C^, 28, it 
generates a secret random number R2, 29 the terminal sends 
both R2 and C^, 32 to the card. The card then performs a 
modular exponentiation 34 on the signed value Q with the 
small exponent T^, using the terminal's modulus T„. This is 
performed by calculating R1'=C2^'^ mod T„. If Rl' is equal 
to Rl, 36 then the card knows that it is dealing with the 
terminal whose ID Tj^ is associated 38 with the modulus T„. 
The card generally contains a modulo arithmetic processor 
(not shown) to perform the above operation. 

The secret random number R2 is signed 40 by the card 
and returned to the terminal along with a certificate signed 
by the CA which relates the card ID to its public information. 
The signing by the card is performed according to an elliptic 
curve signature algorithm. 

The verification of the card proceeds on a similar basis as 
the verification of the terminal, however, the signing by the 
card utilizes an elliptic curve encryption system. 

Typically for an elliptic curve implementation a signature 
component s has the form: 

s=ae+k{mod n) 

where: 

P is a point on the curve which is a predefined parameter 
of the system; 

k is a random integer selected as a short term private or 
session key, and has a corresponding short term public key 
R«kP; 

a is the long term private key of the sender (card) and has 
a corresponding public key aP=Q; 

e is a secure hash, such as the SHA hash function, of a 
message m (R2 in this case) and short term public key R; and 

n is the order of the curve. 

For simplicity it will be assumed that the signature 
component s is of the form s«ae+k as discussed above 
although it will be understood that other signature protocols 
may be used. 

lb verify the signature sP-eQ must be computed and 
compared with R. llie card generates R, using for example 
a field arithmetic processor (not shown). The card sends to 
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the terminal a message including m, s, and R, indicated in 
block 44 of FIG. 2 and the signature is verified by the 
terminal by computing the value (sP-eQ) 46 which should 
correspond to kP. If the computed values correspond 48 then 
the signature is verified and hence the card is verified and the 
transaction may continue. 

The terminal checks the certificate, then it checks the 
signature of the transaction data which contains R2, thus 
authenticating the card to the terminal. In the present 
embodiment the signature generated by the card is an elliptic 
curve signature, which is easier for the card to generate, but 
requires more computation by the terminal to verify. 

As is seen from the above equation, the calculation of s is 
relatively straightforward and does not require significant 
computing power. However in order to perform the verifi- 
cation it is necessary to compute a number of point multi- 
plications to obtain sP and eQ, each of which is computa- 
tionally complex. Other protocols, such as the MQV 
protocols require similar computations when implemented 
over elliptic curves which may result in slow verification 
when the computing power is limited. However this is 
generally not the case for a terminal. 

Although an embodiment of the invention has been 
described with reference to a specific protocol for the 
verification of the terminal and for the verification of the 
card, other protocols may also be used. 

What is claimed is: 

1. A method of verifying the authenticity of messages 
exchanged between a pair of correspondents in an electronic 
transaction conducted over a data transmission system, said 
correspondents each including respective signing and veri- 
fying portions of a first signature scheme and a second 
signature scheme different to said first scheme and utilizing 
an elliptic curve crypto system said method comprising the 
steps of: 

one of said correspondents signing a message according 
to a signing portion of one of said schemes associated 
with said one correspondent to provide a first signed 
message and transmitting said first signed message to 
another of said correspondents; said other correspon- 
dent utilizing said verifying portion of said one signa- 
ture scheme to verify said first signed message received 
from said one correspondent; 

said other correspondent signing a message by utilizing 
said signing portion of the other of said signature 
schemes to provide a second signed message and 
transmitting a second signed message to said one 
correspondent; 

said one correspondent verifying said second signed mes- 
sage received from said other correspondent by utiliz- 
ing said verification portion of said other of said 
signature schemes, wherein one of said signature and 
one of said verifications is performed according to said 
second signature scheme utilizing an elliptic curve 
cryptosystem; and rejecting said transaction if either 
verification fails. 

2. A method as defined in claim 1, said first signature 
scheme is computationally more difficult in signing than 
verifying, while said second signature scheme is computa- 
tionally more difficult in verifying than signing, thereby 
allowing one of said correspondents to participate with 
relatively little computing power while maintaining security 
of said transaction. 

3. A method as defined in claim 1, wherein said first 
digital signature scheme is an RvSA type scheme. 
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4. A method as defined in claim 1, wherein said first 
digital signature scheme is a DSS type scheme. 

5. A method of verifying the authenticity of messages 
exchanged between a pair of correspondents in electronic 

5 transaction conducted over a data transmission system, said 
correspondents each including respective signing and veri- 
fying portions of a first signature scheme and a second 
signature scheme, different from said first scheme and 
utilizing an elliptic curve crypto system said method com- 
prising the steps of: 

one of said correspondents transmitting to another of said 
correspondents, a first certificate including public key 
and identification information of said first correspon- 
15 dent; 

said other correspondent verifying said certificate and 
extracting said public key said identification informa- 
tion therefrom; 

said other correspondent generating a first challenge 
and transmitting said challenge to said one correspon- 
dent; 

said one correspondent signing said received challenge R^j 
in accordance with said signing portion of one of said 
25 signature schemes to provide a second certificate C2; 

said one correspondent generating a second challenge and 
transmitting said second challenge along with said 
certificate C2 to said other correspondent; 

said other correspondent verifying said certificate C2 in 
accordance with said verification portion of one of said 
signature schemes; 

said other correspondent signing said second challenge 
R2 in accordance with said signing portion of the other 
35 of said signamre schemes to provide a third certificate 
and transmitting said said third certificate to said one 
correspondent; and 

said one correspondent verifying said third certificate in 
accordance with said verification portion of said other 
of said signature schemes, and rejecting said transac- 
tion if either said signature is not verified. 

6. A smart card for use in an electronic transaction with a 
correspondent, said card comprising: 

a memory including 

a verification algorithm of a first signature scheme to 
implement a verification of a signature performed 
according to a first signature generation algorithm by 
said correspondent; 

a signing algorithm of second signature scheme differ- 
ent to said first signature scheme and utilizing efiiptic 
curve cryptography, said algorithm implementing a 
signature according to a second signature generation 
algorithm; 

a program for invoking said algorithms; and 
processor means for running said first verification algo- 
rithm for verifying a first message signed by sad 
correspondent and for running said second signature for 
signing a second message for transmission to said 
correspondent. 

7. A card according to claim 6 wherein said verification 
algorithm verifies an RS A signature. 

8. A card according to claim 6 wherein said verification 
algorithm verifies a DSS signature. 

* * * * « 
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